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GUIDE  TO 


SOFTWARE  CONVERSION  MANAGEMENT 

John  J.  Mayers 

Neil  Katz 
Larry  Hoover 

ABSTRACT 


This  guide  was  developed  to  help  Federal  ADP  managers 
understand  the  entire  process  of  software  conversion  and  manage  that 
process  more  effectively.  Software  conversions  have  life  cycles  with 
distinct  phases.  A  better  understanding  of  the  conversion  process  and  its 
associated  costs,  should  help  managers  to  plan  and  execute  more 
software  conversions  more  efficiently,  effectively  and  with  minimum 
operations  disruption  to  Federal  agencies.  Although  extensive  references 
were  consulted  in  preparing  this  guide,  the  most  important  sources  were 
interviews  conducted  at  fourteen  Federal  agencies  that  had  completed  or 
were  involved  in  software  conversion  projects. 

Keywords:  Conversion  costs;  conversion  planning;  project  management; 
conversion  requirements;  conversion  preparation;  conversion  execution; 
documentation. 


SECTION  1 


INTRODUCTION 


1.1  OVERVIEW 


Previous  studies  of  Federal  conversions  conducted  by  the 
General  Accounting  Office  and  the  National  Bureau  of  Standards  revealed 
that  there  were  management-related  problems  in  the  planning  and 
execution  of  software  conversion  (23,  42,  43).  In  preparing  for  this  guide 
interviews  were  conducted  at  fourteen  Federal  agencies.  Managers  were 
consulted  who  were  involved  in  planning,  preparing  for,  executing,  or 
assisting  in  software  conversions.  These  interviews  revealed  that  the 
management  problems  addressed  by  GAO  and  NBS  persist,  because: 

o      The  total  software  conversion  process  is  not  well 
understood) 


o  This  lack  of  uiKlerstanding  leads  to  inadequate  planning, 
preparation  and  a  failure  to  apply  practical  management 
procedures  at  the  right  time  to  control  the  conversion 
process, 

o  Software  conversion  costs  and  resources  are  not  totally 
understood,  considered  or  applied. 

The  goal  of  this  guide  is  to  provide  information  which  can  be 
used  by  Federal  ADP  system  mane^ers  to  resolve  management  problems 
and  to  accomplish  all  aspects  of  a  software  conversion  in  a  more 
expeditious  and  cost-effective  manner.  Specifically,  this  guide  is  to 
provide  assistance  in  the  following  areas: 

)  o       Understanding  software  conversion, 

o  Planning, 
o      Project  control, 
o  Scheduling, 
o  Staffing, 

o      Application  of  resources. 

There  are  many  references  which  apply  to  software 
conversion.  However,  no  reference  treats  the  entire  software  conversion 
process  from  start  to  finish.  In  this  regard,  this  guide  is  unique.  It 
provides  managers  a  perspective  and  description  of  software  conversion, 
from  project  initiation  through  post  conversion.  It  facilitates  better 
understanding  of  the  conversion  process  and  thus,  better  management.  It 
is  not  intended  for  this  guide,  however,  to  replace 
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other  obligatory  or  useful  directives  and  references.  This  guide  serves  as 
a  supplement  to  other  references  and  facilitates  their  application  to 
specific  agency  conversions. 

Software  conversions  in  the  Federal  government  range  from 
very  large  projects  taking  upwards  of  five  years  to  complete  to  very  small 
projects  lasting  a  matter  of  months.  The  conversions,  which  involve 
both  code  compatible  machines  and  non-code  compatible  machines, 
vary  in  complexity.  Further,  Federal  agencies  differ  considerably 
in  size,  organization  and  function  and  in  their  use  of  ADP.  It  is  not 
feasible  to  develop  a  guide  which  covers  every  software  conversion 
possibility.  Consequently,  this  guide  does  not  dictate  a  single  method  for 
accomplishing  software  conversion;  rather  it  describes  a  broad  range  of 
procedures,  techniques,  considerations  and  activities,  which  if  selectively 
implemented,  will  assist  managers  in  minimizing  the  negative  aspects  of 
software  conversion  upon  an  agency's  ADP  organization,  information 
systems  and  system  users.  It  should  provide  managers  the  insight 
necessary  to  tailor  conversion  planning  and  execution  to  actual  agency 
needs. 

Additionally,  the  guide  stresses  many  of  the  problems  common 
to  conversion  efforts.  These  include  not  only  ^ort  term  problems 
specific  to  a  conversion  such  as  inadequacies  in  project  management,  but 
also  longer  term  problems  which  have  an  impact  on  conversion  and  other 
software  management  considerations  as  welL  An  example  of  the  latter  is 
failure  to  use  stemdardized  languages.  Use  of  non-standard  languages,  not 
only  increases  difficulty  in  conversion  but  also  limits  the  ability  to 
transport  that  software  to  another  agency  which  might  desire  its  use. 

1^  GUIDE  QUALIFICATIONS 

1.2.1  SOFTWARE  CONVERSION-HARDWARE  REPLACEMENT 

Most  software  conversions  result  from  the  need  to  replace 
hardware  systems  because  of  processing  saturation  or  equipment 
obsolescence.  While  there  are  other  reasons  for  software  conversion  (e.g., 
transfer  of  a  mission  from  one  agency  to  another  with  a  concomitant 
transfer  of  information  systems),  this  guide  is  oriented  towards  conversion 
stemming  from  hardware  replacement.  Further,  this  guide  assumes  a 
non-code  compatible  conversion  since  this  conversion  condition  produces 
the  most  problems  and  thus  the  most  management  lessons. 

Users  of  this  guide  are  cautioned  that  hardware  replacement 
has  only  been  addressed  to  support  discussion  of  software  conversion. 
From  a  total  agency  ADP  standpoint  there  are  many  more  hardware  issues 
of  interest  to  memagement.  While  this  guide  provides  a  limited  discussion 
of  some  hardware  replacement  problems,  a  manager  who  is  interested  in 
both  software  conversion  and  hardware  conversion  must  consider  sources 
of  information  other  than  this  guide. 
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1.2.2 


SOFTWARE  CONVERSION  LEVEL  OF  EFFORT 


This  guide  is  oriented  towards  a  medium-  to  large-scale  effort 


converting  non-data  base  management  systems  (DBMS),  business 
applications.  Since  Federal  system  conversions  range  from  very  small  to 
very  large  and  include  other  types  of  software  such  as  DBMS,  scientific, 
modeling,  and  operating  systems,  managers  may  need  to  modify  this  guide 
to  apply  to  specific  agency  requirements. 

1.2.3  LEVELS  OF  MANAGEMENT 

There  are  essentially  four  levels  of  management  involved  or 
interested  in  software  conversion. 


o  External  Management  -  This  management  is  at  the 
appropriations  or  approval  level,  e.g..  Office  of 
Management  and  Budget. 

o  Top  Management  -  Internal  management  at  the 
department  level  exercising  broad  approval  and  policy, 
and  program  roles. 

o  Technical  -  Middle  management  involved  with 
overall  data  processing,  planning,  and  operations,  e.g., 
manager  of  a  data  processing  activity  or  ADP  manager. 

o  Technical  Supervision/Staff  -  That  management 
responsible  for  specific  data  processing  operations,  e.g., 
the  supervisor  of  systems  analysts  and  programmers. 

This  guide  focuses  on  management  activities  at  the  technical 


management  and  technical  supervision/staff  levels.  These  are  the  levels 
where  exceptional  management  skills  must  be  applied  to  achieve 
successful  conversions. 


This  guide  assumes  a  hypothetical  agency  structure  (see 
Figure  1-1). 


o  Top  managers  are  those  whose  day-to-day  interests 
concern  overall  agency  functions  and  who  exercise  broad 
approval  and  policy  and  program  roles.  Nevertheless 
their  support  and  understanding  of  software  conversion 
issues  are  important  to  the  success  of  any  conversion 


1.2.4 


AGENCY  STRUCTURE 


(18). 


o 


Functional  users  are  the  users  of  agency  information 
system  (e.g.,  personnel,  finance).  They  assist  in  software 
conversion,  particularly  in  parallel  testing. 
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o  The  ADP  manager  is  the  manager  of  all  agency  data 
processing  activities  -  both  hardware  and  software. 

o  The  hardware  and  operations  manager  is  responsible  for 
day-to-day  machine  and  communications  operations. 

o  The  software  manager  is  responsible  for  day-to-day 
applications,  programs  development  and  maintenance  as 
well  as  systems  programming.  During  software 
conversion  this  manager  has  an  added,  paramount 
interest  in  conversion  activities.  In  the  post-conversion 
phase  this  manager  also  ensures  that  post  conversion 
plans  and  activities  are  accomplished.  Thus,  this 
manager  has  a  strong  coordination  function  with  the 
conversion  project  manager. 

o  The  conversion  project  manager  is  assigned  full-time 
during  the  software  conversion  process.  After 
conversion  is  completed  the  project  manager  returns  to 
normal  duties  associated  with  day-to-day 
responsibilities.  On  a  large  conversion  project  there  may 
be  a  full-time  project  management  team. 

Many  conversion  problems  result  because  of  lack  of 
understanding  of  conversion  management  issues  on  the 
part  of  upper  level  management.  It  is  to  a  software 
conversion  mcmager's  advantage  to  achieve  as  much 
software  conversion  project  visibility  as  possible  in  order 
to  effectively  compete  for  management  attention  and 
resources.  In  this  regard  the  software  conversion  project 
m€uiager  has  been  placed  directly  under  the  ADP 
manager  in  order  to  illustrate  the  need  for  high  level 
visibility. 


1.3  HBTORY  OF  SOFTWARE  CONVERSION 

Software  conversion  is  generally  viewed  in  the  Federal  ADP 
community  as  a  traumatic  and  disruptive  experience,  to  be  avoided  as 
long  as  possible,  endured  when  necessary,  and  forgotten  as  quickly  as 
possible.  However,  software  conversions  are  common  in  the  Federal 
government  Hardware  systems  are  replaced  on  an  average  of  every 
seven  to  eight  years  (23).  The  information  systems  processed  on  this 
hardware  system  commonly  have  a  much  longer  life  span,  particularly 
major  applications  supporting  such  functions  as  finance  and  accounting, 
personnel,  and  payroll  This  means  that  conversion  is  a  historical  step 
rather  than  an  aberration  in  an  information  system's  life  cycle.  If  it  is 
viewed  «is  a  recurring,  historical  event,  management  practices  can  be 
applied  to  improve  conversion  as  they  are  applied  to  improve  other 
software  processes  in  the  life  cycle. 
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1.4 


SOFTWARE  CONVERSION  IN  THE  INFORMATION  SYSTEM 
LIFECYCLE 


The  traditional  and  well  understood  model  of  an  information 
system's  life  cycle  is  depicted  in  FIPS  PUB  38,  Guidelines  for 
Documentation  of  Computer  Programs  and  Automated  Data  Systems  and 
FIPS  PUB  64,  Guidelines  for  Documentation  of  Computer  Programs  and 
Automated  Data  Systems  for  the  Initiation  Phase  (22,  25)  (see  Figure  1-2). 
If  conversion  is  acknowledged  as  part  of  the  information  system's  life 
cycle,  it  couki  be  placed  in  the  software  life  cycle's  operations  phase  (see 
Figure  1-3). 

Examination  of  the  activities  or  processes  which  constitute 
software  conversion  reveals  that  there  is  a  conversion  life  cycle  imbedded 
in  the  overall  information  system's  life  cycle.  This  software  conversion 
life  cycle,  itself,  has  distinct  phases  (see  Figure  1-4). 

o  Project  Initiation  -  The  phase  in  which  management 
acknowledges  software  conversion  is  a  distinct  possibilty 
in  the  near  term.  Managers  determine  if  conversion 
must  be  accomplished  or  if  feasible  alternatives  exist 
(e.g.,  improving  the  existing  hardware  system  capacity, 
shifting  workload  to  another  computer,  or  improving  the 
efficiency  of  existing  software). 

o  Conversion  Requirements  -  The  phase  in  which,  after 
determining  that  conversion  must  be  accomplished, 
studies  and  analyses  are  conducted  to  identify  all  agency 
conversion  requirements  and  cost  estimates  in  detaiL 

o  Conversion  Planning  -  The  phase  in  which  conversion 
details  are  translated  into  detailed  conversion  plans. 


o  Conversion  Preparation  -  During  this  phase  all 
preparation  activities  leading  to  actual  software 
conversion,  itself,  are  conducted. 

o  Conversion  Process  -  The  phase  during  which  software  is 
actually  converted. 

o  Post  Conversion  -  During  this  phase  the  conversion 
project,  per  se,  ends.  Long-range  planning  is  conducted 
for  the  next  conversion.  Management  also  has  the 
opportunity  to  improve  the  next  conversion  by 
implementing  practices  and  measures  which  are 
conducive  to  efficient  conversion.  The  later  stages  of 
the  post  conversion  phase  eventually  lead  to  the  next 
project  initiation  phase. 
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The  phased  approach  of  viewing  software  conversion  provides 
the  structure  for  this  guide.  However,  in  an  actual  conversion  many  of 
the  activities  associated  with  each  phase  proceed  in  parallel  (see 
Figure  1-5).  For  example,  this  guide  treats  planning  as  a  phase  although 
planning  is  a  continuous  process.  Likewise,  while  conversion  requirements 
are  being  developed,  preparation  activities  can  be  ongoing.  Similarly, 
some  software  conversion  may  commence  before  preparations  are 
finished.  The  reader  or  user  of  this  document  is  asked  to  keep  in  mind 
that  the  sequential,  or  phased  approach  to  this  guide  presentation  must  be 
tempered  with  the  understanding  that  different  activities  also  proceed  in 
paralleL 

1.5  PROJECT  INrriATION  PHASE 

This  is  the  phase  in  which  management  determines  that 
software  conversion  is  a  distinct  possibility  in  the  near  term.  A 
conversion  project  manager  is  appointed  and  a  small  project  team  is 
assembled.  A  feasibility  study  is  accomplished  to  determine  if 
alternatives  to  conversion  exist.  If  the  most  feasible  alternative  is 
procurement  of  new  hardware,  preliminary  planning  commences.  In 
addition  to  the  feasibility  study  other  studies  may  be  performed  (e.g.,  to 
satisfy  the  requirements  of  Office  of  Management  and  Bucket  (0MB) 
Circular  A -76,  Policies  for  Acquiring  Commercial  or  Industrial  Products 
and  Services  for  Government  Use  and  0MB  Circular  A-1 09,  Major 
Systems  Acquisition). 

There  are  two  management  pitfalls  to  avoid  in  this  phase: 
failure  to  appoint  a  full  time  project  manager  with  the  authority  and 
responsibility  to  complete  the  initial  planning  and  manage  the  conversion 
effort  from  start  to  finish,  and  failure  to  start  studies  and  planning  early. 
Many  conversion  projects  are  delayed  while  inadequate  plans  are 
strengthened  or  experience  slippages  later  in  conversion  due  to  planning 
oversights. 

Key  top  management  decisions  are  appointment  of  a  project 
manager,  approval  of  feasibility  and  other  studies  as  required  (e.g., 
OMB  Circulars  A-''6  and  A-109). 
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1.6  CONVERSION  REQUIREMENTS  PHASE 


After  approval  of  the  feasibility  study,  the  project  manager 
and  project  team  develop  the  details  necessary  to  completely  plan  the 
conversion.  Alternatives  to  many  conversion  activities  (e.g.,  choosing 
specific  automated  conversion  tools)  (jje  decided  on  a  cost-effective 
basis. 

The  project  manager  also  develops  a  software  conversion  study 
in  this  phase  which  is  used  to  support  an  agency  procui>ement  request 
(APR)  submitted  to  the  General  Services  Administration  (GSA)  for 
hardware  procurement.  This  study  must  be  well  constructed  and  carefully 
costed.  It  is  particularly  important  to  examine  software  conversion  costs 
from  a  standpoint  of  converting  to  code  compatible  versus  non-code 
compatible  hardware.  Generally,  cost  avoidances  can  be  high  in  a 
code-compatible  conversion,  but  this  approach  must  be  fully  justified  and 
supported. 

In  addition  to  the  software  conversion  study,  other  studies 
initiated  in  accordance  with  OMB  Circulars  A-76  and  A-109  may  be 
ongoing  and  require  input. 

It  is  important  to  address  security  and  privacy  requirements  in 
this  phase.  These  tend  to  be  overlooi<ed  from  a  systems  standpoint  but 
are  extremely  important.  Incorp>orating  security  and  privacy  features  into 
software  during  conversion  is  relatively  straightforward  if  considered  and 
planned  well  in  advance. 

The  major  maneigement  issue  in  this  phase  is  maintaining 
continuity  of  the  project  manager  and  project  team  to  allow  them  to 
develop  the  software  conversion  study  and  the  details  necessary  for 
thorough  planning. 

The  key  management  decision  is  approval  of  the  software 
conversion  study. 

1.7  CONVERSION  PLANNING  PHASE 

As  the  detailed  requirements  are  developed,  they  are 
converted  into  conversion  plans  to  support  staffing,  acquiring  conversion 
contractor  support,  locating  the  conversion  project  team,  acquiring 
necessary  conversion  facilities  such  as  terminals,  training,  and 
accomplishing  the  actual  conversion.  Tracking  mechanisms  are  also 
developed  to  keep  management  apprised  of  conversion  progress.  If  a  fully 
competitive  hardware  selection  is  in  progress,  planning  must  remain 
flexible  until  the  target  hardware  is  known.  The  conversion  project 
manager  maintains  close  coordination  with  agency  personnel  involved  in 
hardware  acquisition  in  order  to  gain  early  insight  of  planning  impacts 
stemming  from  acquisition  decisions. 

The  key  management  decision  in  the  conversion  planning  phase 
is  approval  of  all  conversion  plans  necessary  to  complete  the  conve^v^on. 


11 


1.8  CONVERSION  PREPARATION  PHASE 


After  conversion  plans  are  developed,  preparations  are  made 
for  concentrated  conversion  of  software.  Preparations  should  be 
complete  prior  to  conversion  to  preclude  interruptions  and  wasted  effort. 
Major  preparation  activities  include  assembling  and  training  the 
conversion  team,  developing  or  obtaining  conversion  tools,  installing 
equipment,  obtaining  conversion  facilities,  developing  test  data  and 
contracting  for  conversion  support.  Tracking  of  conversion  preparation 
plans  ensures  that  schedules  are  met. 

A  major  management  concern  in  the  conversion  preparation 
phase  is  dealing  with  unforeseen  problems  such  as  unanticipated  personnel 
losses  and  outside  impacts  such  as  budget  cuts.  Plans  must  remain 
flexible  to  accommodate  these  problems. 

The  key  management  decision  in  this  phase  is  approval  to 
proceed  with  the  conversion. 

1.9  CONVERSION  PHASE 

During  this  phase  software  is  converted.  Unit,  system  and 
parallel  testing  is  conducted  and  operational  systems  are  accepted  by  the 
information  system  users. 

The  critical  management  issues  are  dealing  with  unforeseen 
problems  to  keep  the  conversion  on  track,  monitoring  contractor 
performance  for  compliance  with  Statements  of  Work  and  ensuring  that 
established  agency  software  standards  are  met  and  documentation  is 
produced. 

The  conversion  phase  ends  when  the  last  converted  system  is 
accepted  by  the  functional  user.  A  key  management  decision  in  this  phase 
deals  with  accepting  software  which  may  not  have  completed  parallel 
testing  (e.g.,  it  may  not  be  practical  to  parallel  test  year-end  reporting). 
Considerable  risk  is  removed  if  the  agency  has  developed  and  maintained 
good  test  data,  and  unit  and  systems  tests  have  been  successfuL 

1.10  POST  CONVERSION  PHASE 

The  first  activities  of  the  post-conversion  phase  involve 
disbanding  the  conversion  project  team  and  reorganizing  the  agency 
software  operations  into  a  normal,  day-to-day  environment.  The  project 
manager  should  conduct  a  post-conversion  study  and  assess  and  record  the 
entire  conversion  experience.  Completion  of  activities  to  settle  the  staff 
in  a  normal  software  environment  and  the  post-conversion  analysis  and 
assessment  complete  the  conversion  project.  This  post-conversion 
analysis  and  assessment  has  much  utility  in  that  it  provides  a  historical 
reference  of  lessons  learned,  that  may  be  applied  in  future  conversions.  It 
also  facilitates  planning  for  the  next  conversion.  This  planning  should 
begin  immediately  and  should  continue  until  the  next  conversion. 
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In  addition  to  planning,  agency  software  standards  should  be 
enforced  during  the  post  conversion  phase.  Use  of  these  standards  will 
make  the  next  conversion  easier.  Software  security  and  privacy 
requirements,  applied  in  a  routine  systematic  fashion,  will  reduce  the 
chance  for  oversight  in  a  crisis  conversion  environment. 

The  critical  management  issues  in  post  conversion  are 
completing  the  post  conversion  analysis  and  assessment,  developir^  and 
maintaining  conversion  planning,  and  ensuring  that  software  is  developed 
and  maintained  to  high  technical  standards. 

The  key  management  decision  in  the  post  conversion  phase  is 
approving  the  post-conversion  plan.  This  terminates  the  conversion 
project. 

1.11  APPENDICES 

The  remainder  of  this  guide  follows  the  phases  of  the 
conversion  life  cycle  presented  above.  Appendices  to  the  guide  include: 

BIBLIOGRAPHY 

Appendix  A  is  the  bibliography  which  was  used  in  developing 

this  g^ide. 

CONVERSION  DIRECTIVES  STANDARDS  AND  REFERENCES 

Appendix  B  contains  a  list  of  directives  and  references  that 
are  applicable  to  software  conversion.  They  are  recommended  to  be  part 
of  any  software  conversion  manager's  library. 

SOFTWARE  CONVERSION  COSTING 

Appendix  C  contains  a  costing  methodology  that  managers  can 
use  to  develop  software  conversion  cost  estimates.  It  can  be  used  in  the 
feasibility  study  during  the  project  initiation  phase,  the  software 
conversion  study  to  support  the  agency  procurement  request,  agency 
budgets,  and  to  support  any  other  cost  requirements. 

CASE  STUDIES 

Appendix  D  contains  software  case  studies  that  were 
developed  from  actual  c^ency  experiences.  They  provide  additional 
insight  into  software  conversion's  management  issues. 

GLOSSARY 

Appendix  E  contains  a  glossary  of  terms  used  in  this  guide. 
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SECTION  2 


PROJECT  INITIATION  PHASE 


A  point  is  reached  in  every  information  system's  life  cycle 
where  conversion  is  considered  in  detaiL  The  causes  of  conversion  vary 
but  are  usually  related  to  a  real  or  perceived  need  to  replace  hardware. 
Eventually  managers  realize  that  software  conversion  is  no  longer  an 
event  to  be  faced  at  some  undetermined  time  in  the  distant  future,  but  a 
condition  that  is  likely  to  occur  and  that  requires  initial  but  definitive 
consideration  and  planning. 

Prior  to  any  extensive  commitment  of  resources  to  support  a 
full  scale  software  conversion,  a  feasibility  study  is  required  by  General 
Services  Administration  41  CFR  Part  1-4  ,  to  firmly  establish  the  need  for 
a  conversion  effort.  There  may  be  viable  alternatives  to  a  conversion, 
such  as  keeping  the  present  computer  system  running  for  longer  periods  of 
time  (e.g.,  3rd  shift,  weekends),  reducing  the  workload  by  identifying  and 
cutting  nonessential  processing,  or  distributing  some  of  the  workload  to 
other  computers. 

In  addition  to  providing  decisive  information  on  whether  or  not 
a  conversion  is  necessary,  preliminary  plannir^  provides  management 
early  insight  on  the  magnitude,  direction,  resource  requirements,  and  cost 
of  the  software  conversion  project. 

The  time  associated  with  project  initiation  activities, 
especially  the  planning,  the  estimating  and  statistical  development,  and 
conduct  of  the  feasibility  study  should  not  be  underestimated.  Two  to 
three  person  years  of  effort  over  six  months  could  be  required  for  a 
medium  to  large  scale  conversion. 

A  positive  attitude  toward  conversion  siiould  be  developed  in 
the  software  staff.  Rather  than  viewing  conversion  as  a  disruptive 
process,  conversion  can  be  approached  as  professionally  challenging,  an 
opportunity  to  broaden  professional  skills,  and  to  exercise  initiative  in  a 
dynamic  environment.  Conversion  also  offers  an  opportunity  to  upgrade 
the  status  of  agency  software  to  high  technical  standards.  For  example, 
old  inefficient  programs  can  be  rewritten  in  standard  languages  using 
modern  software  engineering  techniques.  Documentation  can  be  updated 
and  made  current.  Unnecessary  or  outdated  code  can  be  eliminated. 

2.1  REASONS  FOR  CONVERSION 

There  are  many  reasons  for  software  conversion.  Each  reason 
has  different  effects  on  agency  software  conversion  processes  and 
management  involvement. 
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o  Hardware  Processing  Limits:  Computer  systems' 
saturation  is  the  normal  cause  of  software  conversion. 
Hardware  systems  are  commonly  installed  and 
continually  upgraded  to  accommodate  fi^ency 
information  systems  as  they  are  designed,  implemented 
and  enhanced.  Eventually  the  point  is  reached  where  the 
hardware  capacity  for  expansion  no  longer  exists, 
information  systems  no  longer  are  responsive  to 
functional  user  needs,  and  little  or  no  hardware 
resources  are  available  for  new  application  program 
development.  In  unusual  cases,  primarily  due  to  poor 
plannir^,  hardware  systems  upon  installation,  are 
expanded  to  capacity  in  a  matter  of  months.  Commonly, 
however,  hardware  systems  last  approximately  eight 
years  before  capacity  limitations  cause  replacement.  In 
the  normal  case,  software  managers  ^ould  be  able  to 
anticipate  conversion  well  in  advance  through  analysis  of 
trends  and  have  ample  time  to  take  all  actions  necessary 
to  initiate  conversion  in  an  orderly  fashion. 

o  Change  in  Missions  and  Functions;  Federal  agencies 
operate  in  a  dynamic  environment.  Missions  and 
functions  can  change  as  a  result  of  new  Federal  laws  and 
programs,  and  as  a  result  of  agency  consolidations  and 
reorganizations.  As  established  agencies  gain  additional 
missions  and  functions,  their  information  requirements 
increase.  These  increased  information  requirements 
result  in  new  demands  for  information  systems  which 
ultimately  lead  to  hardware  saturation.  However,  in  the 
case  of  hardware  saturation  caused  by  mission  and 
function  changes,  conversion  can  be  precipitated  in  a 
much  more  dramatic  and  Sorter  time  frame  than  as  a 
result  of  saturation  due  to  normal  systems  growth.  Thus, 
when  mission  and  functions  change,  software  managers 
usually  have  less  time  to  initiate  software  conversion 
projects. 

o  Operational  Requirements:  Retaining  existing 
application  system  software  may  no  longer  be 
operationally  viable.  For  example,  vendor  software  may 
no  longer  be  supported  by  the  vendor.  The  existing 
software,  without  vendor  maintenance  support,  may  not 
be  useful  for  new  systems  development  and  existing 
system  enhancements.  Rather  than  retain  obsolete, 
unsupported  software  for  some  systems  and  introduce 
new  software  for  new  systems,  with  attendent 
requirements  for  increased  and  different  training  and 
documentation,  agencies  may  convert  all  software  to  a 
viable  language.  Another  example  of  conversion  caused 
by  operational  requirements  has  to  do  with  old  software 
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running  in  an  emulation  mode.  Long-term  emulation 
processing  is  generally  inefficient  for  software  that  is 
frequently  used.  Managers  may  decide  from  a  cost 
effective,  as  well  as  operational  standpoint,  to  convert 
software  running  in  an  emulation  mode. 

o  Technology:  Some  Federal  computer  systems  do  not 
become  saturated  and  are  useful  for  many  years. 
Eventually,  however,  their  age  or  lack  of  technological 
sophistication  dictate  their  replacement.  Vendors  or 
manufacturers  eventually  discontinue  maintenance  and 
other  support  to  old  hardware.  In  other  cases,  even 
though  support  is  still  available,  operating  costs 
associated  with  operations'  staff,  power,  and  air 
conditioning  may  be  unacceptable.  Modem  hardware  and 
software  may  support  the  same  functional  applications 
at  considerably  reduced  operational  cost. 

2JZ  PROJECT  INITIATION  OBJECTIVE 

The  objective  of  the  project  initiation  phase  is  to  conduct  the 
preliminary  planning  and  studies  to  determine  whether  a  conversion  should 
be  undertaken. 

2.3  PROJECT  INITIATION  ACTIVrriES 

The  following  activities  occur  durii^  the  project  initiation 
phase  (see  Figure  2-1): 

o  Project  manager  appointment  and  project  team 
establishment, 

o  Information  system  user  and  top  management  interface, 

o  Project  reporting  and  control, 

o  Preliminary  planning  and  estimating, 

o  Accompli^ing  a  feasability  study  and  cost  analysis, 

o  Management  decisions. 


2.4  PROJECT  MANAGEMENT  APPOINTMENT  AND  PROJECT 

TEAM  ESTABLBUMENT 

Of  prime  importance  to  a  successful  conversion  is  the 
appointment  of  a  project  manager  with  the  requisite  technical/managerial 
background  and  the  tenure  and  authority  to  manage  the  conversion 
project.  Concurrently,  a  project  team  should  be  formed  with  the  skills 
and  experience  necessary  to  accomplish  the  studies  and  analyses 
associated  with  the  project  initiation  phase. 
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PROJECT  MANAGEMENT  APPOINTMENT 

PROJECT  TEAM  APPOINTMENT 

USER  &  MANAGEMENT  INTERFACE 

REPORTING  &  CONTROL 
ESTABLISHMENT 

PRELIMINARY  PLANNING 

FEASIBILITY  STUDY  PREPARATION 


MANAGEMENT  DECISION  T 

PROJECT  INITIATION  PHASE  ACTIVITIES 
Figure  2-1 
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The  establishment  of  the  project  manager  and  project  team 
should  include  provisions  for  adequate  logistical  and  administrative 
support  and  a  sufficient  operational  budget. 

To  be  effective,  there  should  be  a  separation  between  previous 
responsibilities  and  the  conversion  effort.  The  project  team,  as  a  unit, 
should  work  in  a  separate  physical  location.  This  location  will  serve  as 
the  focal  point  for  the  conversion.  Distractions  and  interruptions  will 
then  be  minimized,  allowii^  the  team  to  concentrate  on  the  conversion 
activities. 

The  appointment  of  the  project  manager  and  project  team 
usually  signifies  the  beginnir^  of  software  conversion  cost  expenditures. 
At  this  point  direct  costs  can  be  identified  to  a  particular  project.  Also, 
the  assignment  of  a  project  manager  is  accompanied  by  accountability  for 
project  cost  as  part  of  the  management  responsibilities. 

2.4.1  PROJECT  MANAGER  APPOINTMENTS 

A  full  time  project  manager  should  be  selected  and  apT^ointed 
who  will  have  experience  and  tenure  to  manage  software  conversion  from 
project  initiation  to  project  completion.  While  this  may  appear  self 
evident,  a  sigfnificant  number  of  Federal  conversion  projects  have 
experienced  difficulties  because: 

o  Conversion  project  management  duties  were  assumed  as 
additional  responsibilities  by  fully  committed  software 
stfiff  members. 

o  Project  management  was  not  exercised  continuously 
through  the  different  conversion  phases.  This  lack  of 
continuity  disrupted  and  impeded  conversion. 

The  qualifications  to  be  considered  in  selecting  a  project 
manager  should  include: 

o      Planning  ability, 

o      Ability  to  organize  and  manage  resources, 

o  Project  management  and  software  conversion  experience 
-  Six  to  ten  years  of  experience  is  recommended, 

o  Ability  to  deal  effectively  with  people,  particularly 
personnel  in  agency  elements  external  to  ADP,  such  as 
the  functional  users  of  information  systems, 

o  Ability  to  react  to  problems  and  redirect  efforts  to 
resolve  issues  before  they  get  out  of  hand. 
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While  conversions  should  have  only  one  project  manager,  it  is 
conceivable  that  very  large  conversions  might  have  a  full-time  project 
management  team  appointed  for  the  duration  of  the  project. 

The  project  manager  *ould  be  formally  appointed  and 
chartered  in  writing.  The  appointment  should  be  approved  by  top  agency 
officials.  This  provides  project  visibility  and  acknowledgement  that  the 
project  manager  has  the  authority  to  receive  support  and  assistance  from 
other  organizational  elements  within  the  agency. 

2.4.2  PROJECT  TEAM  ESTABLISHMENT 

The  composition  of  the  project  team  for  this  phase  will  depend 
upon  several  variables,  which  include  project  complexity,  timeframe, 
budgetary  and  personnel  constraints. 

Since  project  initiation  activities  are  planning  oriented,  the 
project  team  should  include  one  or  more  systems  analyst(s),  with  three 
years  minimum  analytical  and  planning  experience  preferred.  Team 
members  must  be  familiar  with  the  current  ADP  environment  and 
applications,  and  be  able  to  collect  and  evaluate  workload  statistics. 
Preference  should  go  to  selecting  those  personnel  with  previous 
conversion  experience.  Although  the  team  during  this  phase  may  be  very 
small,  additional  members  can  be  added  or  reassigned  as  needs  arise. 
Many  managers  use  their  most  experienced  personnel  to  assist  in  project 
initiation  activities  and  continue  to  employ  them  in  other  subsequent, 
conversion  activities. 

2.5  INFORMATION  SYSTEM  USER  AND  TOP  MANAGEMENT 

INTERFACE 

Software  conversion  can  be  a  lengthy  and  complex  process 
dealing  with  an  important  tigency  asset  —  its  information  base.  Software 
conversion  alters  this  data  base.  Problem -ridden  conversions  can  result  in 
considerable  harm  to  an  agency  and  its  operations.  Conversely,  efficient 
conversions  can  improve  the  information  processing  posture  of  an  agency. 
Therefore,  it  is  extremely  important  that  the  functional  users  of 
automated  information  systems  and  top  agency  executives  understand  the 
issues  of  software  conversion  and  support  the  conversion  effort. 
Experience  has  shown,  however,  that  full  functional  user  and  top 
management  understanding  and  support  are  frequently  not  achieved. 

To  overcome  this,  at  project  initiation,  the  project  manager 
can  employ  a  variety  of  techniques  to  develop  and  maintain  user's  and 
management's  interest  and  involvement  in  the  conversion  effort.  These 
include: 
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o  Briefings.  Scheduled  briefings  are  recommended  to  keep 

users  and  top  agency  executives  apprised  of  project 
initiation  activities.  These  briefings  need  not  be  formaL 
Short  presentations  as  part  of  staff  meeting  agendas  can 
be  quite  effective,  especially  since  these  meetings 
provide  an  opportunity  to  inform  many  managers  and 
executives  at  one  time  of  the  conversion  project  status. 
Such  briefings  are  of  particular  importance  to  top 
management.  During  the  project  initiation  phase, 
agency  executives  will  decide  on  conversion  as  a  result 
of  a  feasibility  study  developed  by  the  project  manager 
and  the  project  team.  Regular  briefings  reduce  the 
chance  of  surfacing  surprises  in  the  feasibility  study,  a 
point  appreciated  by  management.  Study  issues  can  be 
raised  well  in  advance  for  executive  level  attention. 
Once  scheduled  briefings  are  established,  they  should  be 
continued  throughout  the  conversion  effort  until  the 
project  is  complete. 

o  Memoranda.  Informal  memoranda  with  general 
information  of  ongoir^  and  planned  activities  might  be 
employed. 

o  Management  Staff  Involvement.  If  it  is  difficult  to 
directly  inform  top  level  managers  of  progress,  it  may  be 
possible  to  inform  or  involve  subordinate  members  of 
his/her  staff  who  have  immediate  access  and  are  charged 
with  keeping  top  level  managers  informed  of  significant 
issues  or  potential  problem  areas. 

o  Articles  in  Agency  Newsletters.  Frequent  but  short 
articles  can  keep  top  managers  and  users  informed  of  the 
software  conversion  project. 

2.6  PROJECT  REPORTING  AND  CONTROLS 

Effective  reportir^  and  controls  must  be  established  and 
adhered  to  during  a  software  conversion.  Without  some  mechanism  for 
accounting  for  work  in  progress,  work  completed,  and  work  to  be  started, 
the  project  manager  will  have  great  difficulty  in  project  tracking  and 
monitoring. 

2.6.1  REPORTING 

At  project  initiation,  reporting  procedures  can  either  be 
separate  from,  or  merged  with,  other  on-going,  related  actions  (e.g., 
hardware  replacement).  These  procedures  should  provide  reports  required 
by  the  project  manager  as  well  as  higher  levels  of  management.  The 
initial  framework  for  internal  and  external  reporting  should  be  formulated 
for  the  entire  conversion  effort. 
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2.6.2 


PROJECT  HISTORY 


A  project  history  should  also  be  started  during  the  project 
initiation  phase.  Thereafter  it  should  be  maintained  by  the  project 
manager  throughout  the  entire  software  conversion  effort.  The  history 
should  reflect  significant  project  actions,  events,  costs,  problems  and 
means  of  problem  resolution.  It  should  also  contain  thoughts  and 
observations  of  how  subsequent  project  activities  or  future  conversions 
can  be  improved.  This  history  can  be  recOTded  in  a  journal  or  1<^  or  be 
contained  in  a  project  reference  file.  Ultimately  the  history  log,  if 
maintained,  will  be  an  invaluable  reference  in  developing  conversion  plans 
and  a  post  conversion  analysis  and  assessment. 

2.6.3  PLANNING  AIDS 

Project  planning  aids  exist  and  include  PERT,  GANTT,  and 
Work  Breakdown  Structures  (WBS).  Project  planning  aids  selected  for  use 
are  largely  a  matter  of  individual  preference  on  the  part  of  a  project 
manager.  However,  at  a  minimum  it  is  recommended  that  some  visual, 
time  d^endent,  planning  aid  ^ch  as  bar  charts  be  used.  Although  bar 
charts  do  not  depict  a  critical  path,  they  identify  concurrent  activities  to 
alert  the  project  manager  of  resource  constraining  areas  that  require 
special  attention.  They  also  visually  portray  starting  and  ending  points  of 
project  activities  and  important  milestones. 

2.7  PRELIMINARY  PLANNING 

Adequate  ADP  project  planning  is  one  of  the  most  critical 
factors  of  a  successful  software  conversion.  Federal  procurement 
regulations  require  a  feasibility  study  to  be  accomplished  before  any 
conversion  to  determine  if  other  alternatives  can  resolve  an  agencies' 
information  processing  problems. 

Additionally,  other  related  studies  are  often  required  in  the 
same  approximate  time  frame  as  the  feasibility  study.  Software 
conversion  results  in  a  change  to  agency  operations.  0MB  Circular  A-76, 
Policies  for  Acquiring  Commercial  or  Industrial  Products  and  Services  for 
Government  Use,  requires  examination  of  ADP  operations  at  a  time  of 
significant  change  to  determine  if  (derations  can  be  effectively  turned 
over  to  a  contractor.  Also,  an  agency  may  consider  hardware 
replacement  and  software  conversion  to  fall  under  the  provisions  of  0MB 
Circular  A-109,  Maior  Systems  Acquisition.  The  project  manager  must 
have  the  planning  and  statistical  base  to  accomplish  the  feasibility  study 
or  provide  input  into  these  other  related  conversion  studies,  as  required. 

Unfortunately,  software  conversion  preliminary  planning  is 
frequently  postponed  to  a  point  where  it  has  an  adverse  effect  on 
conversion  schedules,  or  is  conducted  inadequately  and  without  sufficient 
detail,  ultimately  leading  to  project  slippage.  To  overcome  this 
management  issue  and  to  provide  a  firm  foundation  for  the  feasibility 
study  and  other  related  studies  for  which  input  might  be  required,  early 
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preliminary  plans  should  be  developed  to  provide  managers  insight  into  the 
probable  magnitude  of  the  conversion  project,  gross  resource 
requirements  and  the  probable  length  of  time  conversion  will  take.  This 
can  be  accomplished  by  J 

o  Current  procurement  and  acquisition  regulations  and 
policy  review, 

o  Current  A  DP  hardware  and  system  software  inventory, 

o  Preliminary  systems  and  applications  program  inventory, 

o  Data  file  inventory, 

o  Preliminary  workload  estimation, 

o  Levels  of  effort  and  resource  estimation, 

o      Preconversion/conversion  cost  methodology 

development. 

These  activities  accomplished  by  the  project  team  during 
project  initiation  will  provide  a  statistical  and  planning  base  for  aU 
subsequent  conversion  phases  and  activities. 

2.7.1  CURRENT        PROCUREMENT        AND  ACQUISITION 
REGULATIONS  AND  POLICY  REVIEW 

Along  with  agency  policy  regulations,  there  are  many 
pertinent  Federal  procurement  regulations  and  directives  promulgated  by 
GSA,  OMB  and  Congress,  as  well  as  standards  and  guidelines  promulgated 
by  the  National  Bureau  of  Standards,  that  pertain  to  software  conversion. 
The  project  manager  and  the  project  team  should  review  this  pertinent 
documentation.  Of  particular  importance  are  the  following  three  areas 
addressed  by  these  documents: 

o       Hardware/software  planning  and  acquisition, 
o      Software  conversion, 

o      Timesharing  and  remote  computing  services. 

Appendix  B  to  this  guide  contains  the  most  important 
references  that  will  assist  in  policy  and  regulation  review. 

2.7.2  CURRENT   ADP    HARDWARE    AND   SYSTEM  SOFTWARE 
INVENTORY 

The  purpose  of  this  activity  is  to  document  all  currently 
existing  ADP  equipment  and  system  software  in  order  to  establish  the 
current  environment,  and  identify  any  potential  vendor's  unique  problems 
if  converting  the  application  programs  to  noncompatible,  target  hardware 
is  necessary. 
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2.7.2.1 


Hardware  Inventory 


A  hardware  inventory  is  necessary  to  understand  the 
environment  in  which  the  software  operates.  Also,  costs  associated  with 
hardware  influence  software  feasibility  studies.  The  project  manager  or 
the  project  team  will  be  furnished  the  hardware  inventory  by  the 
hardware  staff.  If  not,  the  project  team  will  have  to  establish  it.  The 
hardware  inventory  and  equipment  configuration  should  describe  and 
display  all  ADPE  components  and  peripherals,  located  either  on-site  or  at 
remote  locations.  At  a  minimum,  this  inventory  should  identify  each 
component  by: 

o      Component  name, 
o       Model  number, 
o      Name  of  manufacturer, 
o  Location. 

Although  primarily  focusing  on  computer  center  equipment, 
such  as  CPU,  disk  components,  tape  drives,  printers,  card  reader/punch, 
and  consoles,  the  inventory  should  also  include  such  items  as  RJ£  stations, 
graphics  equipment,  data  entry  equipment,  and  other  user-oriented 
hardware.  Memory  and  storage  capacity  should  also  be  identified. 
Additionally,  an  inventory  of  all  commmunications  equipment  and  network 
configurations  should  be  acquired  if  data  communications  are  employed. 

2.7.2.2  System  Software  Inventory 

The  system's  software  inventory  must  encompass  not  only  the 
operating  system,  languages,  compilers,  link  editors,  spooling  and 
teleprocessing  software,  but  also  identify  and  describe  utilities,  software 
and  hardware  monitoring  packages.  The  software  inventory  ^ould  include 
at  a  minimum: 

o  Name  of  software  or  language, 

o  Product  number, 

o  Manufacturer, 

o  Version, 

o  Release/level  number, 

o  Version/release  date, 

o  Date  installed, 

o  Local  modifications, 

o  Documentation  available,  location,  and  condition, 

o  System  software  lease,  purchase  or  cost  information. 

Care  must  be  taken  to  document  special  conditions  such  as 
user  exits  and  local  modifications,  where  present. 
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The  software  inventory  will  be  relatively  straightforward  if 
current  system  software  documentation  has  been  maintained.  Where 
little  or  no  documentation  exists,  the  problem  is  magnified,  but  the 
inventory  can  and  must  be  accomplished  To  develop  communications 
between  the  project  team  and  the  system  programming  staff,  and  to 
develop  familiarity  with  systems  software,  it  is  recommended  that  one  or 
two  system  program mmers  temporarily  augment  the  project  team  and 
provide  systems  software  data. 

2.7.3  PRELIMINARY  SYSTEMS  AND  APPLICATION  PROGRAMS 

INVENTORY 

A  preliminary  inventory  of  application  programs  and  systems 
currently  in  use  serves  a  number  of  purposes: 

o  This  inventory  is  required  to  estimate  the  magnitude  of 
the  conversion. 

o  It  serves  as  a  starting  point  in  identifying  those  programs 
and  applications  that  should  be  converted,  if  a 
conversion  is  approved.  A  more  comprehensive  and 
ind^th  inventory  is  undertaken  once  the  conversion 
requirement  phase  starts. 

o  Should  a  conversion  not  be  justified  as  a  result  of  a 
feasibility  study,  the  inventory  will  serve  as  baseline 
documentation  by  the  ADP  staff  during  any  future 
conversion  studies. 

The  application  program  inventory  is  facilitated  if  one  or  more 
of  the  team  members  are  familiar  with  the  applications.  Additional  and 
supplemental  information  can  be  obtained  from  user  groups. 

The  inventory  ^ould  include  at  least  the  following 
infOTmation: 

o       Name  of  system  and  brief  description, 

o  Numbers  and  programs  within  the  system;  lines  of  code 
per  program  and  language;  complexity  of  programming, 

o      Interfaces  with  other  systems, 

o      Data  bases  accessed  by  the  system. 

While  extreme  levels  of  applications  software  detail  are  not 
required  for  project  initiation  activities,  as  much  additional  detail  as 
possible  should  be  devel(^d,  resources  permitting.  This  will  save  time 
later,  during  the  software  conversion  study  conducted  during  the 
conversion  requirements  phase,  when  more  extensive  details  are  needed. 

Cognizant  functional  users  should  review  and  verify  the 
inventory  and  identify  any  applications  that  may  have  been  missed. 
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2.7.4 


DATA  FILE  INVENTORY 


The  project  team  should  identify  and  document  data  files  that 
are  generated  and  processed  by  each  program,  and  files  that  are  shared  by 
multiple  programs  and  systems.  This  inventory  contributes  to  the 
determination  of  the  scale  and  complexity  of  the  current  software 
environment.  The  inventory  is  accomplished  by  one  or  more  members  of 
the  project  team  through  review  of  current  program/system 
documentation,  developed  from  workload  statistical  data  and,  where 
necessary,  interviewing  the  appropriate  users  (39). 

The  inventory  should  include  at  least  the  following 
information: 


o       File  name. 


o       Accessing  system(s)  name(s), 

o       Medium  (i.e.  tape,  disk,  cards,  etc.), 


o       Data  organization  (e.g.  sequential,  random,  indexed, 
etc.), 

o       Code  (e.g.  BCD,  EBCDIC,  ASCII,  etc.), 
o       Estimated  size. 


2.7.5  PRELIMINARY  WORKLOAD  ESTIMATION 


Summary  statistics  are  then  developed  to  reflect  the  basic 
total  system  workload  (e.g.,  percent  CPU  busy,  mean  turnaround,  number 
of  jobs  processed,  etc.)  and  a  profile  established  of  future  workload 
requirements.  Since  time  is  relatively  limited  during  this  phase,  resource 
estimates  should  be  based  primarily  on  available  or  easily  derived  data. 
Most  workload  data  is  usually  available  from  system  operating  statistics 
(e.g.  IBM  System  maintenance  Facility,  "SMF")  and  accounting,  billing 
and  history  data.  The  accumulation  and  summarization  of  detailed, 
resource  workloads  from  hardware/software  monitors  is  usually  too  time 
consuming  at  this  point  in  conversion  planning.  However,  some 
consideration  should  begin  regarding  methods  to  develop  a  more  extensive 
assessment  and  collection  of  workload  data  which  is  required  in  the 
conversion  requirements  phase. 

2.7.6  LEVELS  OF  EFFORT  AND  RESOURCE  ESTIMATION 


Personnel  requirements  are  identified  for  each  conversion 
activity  and  levels  of  effort  are  estimated  for  the  entire  software 
conversion  project.  While  there  are  many  methods  for  estimating 
resources,  a  common  software  conversion  management  method  is 
judgement  based  upon  experience.    The  intent  of  this  guide  is  not  to 
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develop  or  recommend  a  particular  estimating  technique  or  methodology, 
but  rather  to  identify  various  techniques  or  methodologies  that  will  lead 
to  reliable  estimates.  Appendix  C  describes  and  discusses  in  detail  two 
popular  estimation  techniques,  which  include  the  Navy's  PMCS  model  and 
the  Federal  Conversion  Support  Center's  Hybrid  Model  (45).  These  should 
be  assessed  first  before  any  other  models  are  considered. 

2.7.7  DEVELOPING       PRECQNVERSION/CQNVERSION  COST 

METHODOLOGY 

A  software  conversion  cost  methodology  is  described  in  detail 
in  Appendix  C.  A  methodology  should  be  adopted  or  developed  durir^ 
project  initiation  to  provide  a  consistent  basis  for  cost  decisions 
throughout  the  project  as  well  as  for  the  feasibility  study  required  during 
this  phase.  This  cost  methodology  will  be  refined  during  the  project  as 
more  detail  is  developed  and  more  accurate  cost  estimates  can  be 
prepared.  The  cost  methodology  must  be  used  to  track  project  costs.  In 
this  manner,  the  software  conversion  cost  methodology  can  assist  project 
management  by: 

o       Providing  the  ability  to  audit  cost  estimates, 

o      Identifying  the  major  cost  related  efforts, 

o      Providing    a    consistent    cost    information   base  for 
recording  and  projecting  software  conversion  costs. 

2.8  ACCOMPL6HING  THE  FEASIBILITY  STUDY  AND  COST 

ANALYSIS 

The  purpose  of  the  preliminary  feasibility  study  and  cost 
analysis  is  to  determine  if  there  are  alternatives  to  software  conversion 
and  provide  top  management  with  adequate  decision-making  information. 
The  study  will  be  developed  by  the  project  manager  and  project  team.  If 
study  input  is  readily  available,  it  should  take  approximately  two  months 
to  complete.  This  study,  to  be  effective,  must  address: 

0      The  objectives,  assumptions,  constraints,  and  background 
of  the  current  environment, 

o      The  background  and  status  of  the  current  system(s), 

o      Projected  or  anticipated  future  requirements, 

0       Identification  of  alternative  approaches, 

o      A  summary  of  findings  and  recommendation(s)  along  with 
supporting  costs/benefits/ risks  analysis. 
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Unless  there  are  agency  standards,  it  is  suggested  that  FIPS 
PUB  64  be  used  as  a  guideline  in  completing  the  feasibility  study  and  cost 
analysis  (22).  The  following  discussion  is  derived  from  that  reference. 
Figure  2-2  shows  the  relationship  of  the  various  activities  of  the 
feasibility  study  which  are: 

o      Define  Objectives.  Scope,  and  Background 

This  is  the  first  step  in  a  feasibility  study  and  is  to 
define  the  objectives  and  scope  of  effort. 

o       Identify  and  Define  the  Current  System 

The  second  step  is  to  define  the  existing  environment, 
organization,  constraints,  priorities,  and  technical  and 
operational  (workload)  considerations  on  which  this  study 
is  based. 

o      Identify  Alternatives 

This  is  the  key  stage  where  creative  and  intuitive 
thinking  are  employed.  Viable  alternatives  and  solutions 
are  identified  and  described. 

Besides  the  status  quo,  possible  alternatives  might 
include  increasing  the  hours  of  computer  system 
operation,  reducing  non-essential  or  non-productive 
work,  distributive  processing,  or  conversion  to  larger 
hardware. 

o      Assess  Technical  and  Operational  Feasibility 

The  technical  and  operational  feasibility  (i.e.,  satisfying 
user  requirements)  of  each  alternative  is  assessed  to 
determine  if  they  are  suitable  technologically  and 
operationally. 

o      Estimate  Costs  of  Alternatives 

AH  relevant  costs  (i.e.,  recurring,  and  non-recurring  and 
present  value)  of  each  alternative  must  be  estimated. 
Cost  estimates  developed  using  the  software  conversion 
costing  methodology  should  be  based  on  the  full  cost  of 
each  alternative,  and  defined  in  sufficient  detail  to  allow 
cost  comparisons  of  individual  elements  of  cost  among 
alternatives. 
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Define  and  Describe  Benefits 


Identify  and  define  any  quantifiable  and  non-quantifiable 
benefits  or  their  estimated  values  for  each  alternative. 
Do  not  overlook  the  intangible  benefits.  While  these 
may  be  more  difficult  to  estimate  or  assign  values,  in 
many  cases  they  may  carry  more  weight  in  the  final 
analysis  and  decision-makir^.  These  costs  are 

reflected  in  each  alternative,  including  the  status  quo 
alternative.  Care  must  be  taken  to  avoid  double 
counting  of  costs  or  benefits. 

Compare  the  Alternatives 

Compare  the  feasibility  of  each  alternative  in  terms  of 
desirability  and  advantages/disadvantages.  The 
comparison  is  based  upon  the  technical,  cost  and 
operational  factors  identified  above. 

Analyze  Sensitivity  and  Risk 

A  useful  tool  in  feasibility  studies,  is  sensitivity  analysis 
which  is  a  method  few  determining  the  impact  of  changes 
in  assumptions  on  the  total  cost  of  the  alternatives. 
Sensitivity  analysis  should  address  the  range  of  values 
for  assumptions  such  as  workload,  inflation  factors, 
salaries,  number  of  programs,  complexity  and  conversion 
productivity.  In  this  manner  the  least  cost  alternatives 
can  be  identified  for  any  given  range  of  assumption 
values  and  used  with  risk  analysis  to  determine  the 
preferred  alternative. 

Recommendation  and  Implementation  Plan 

At  this  point,  based  upon  the  various  cost/benefit  and 
sensitivity  analysis  results,  a  recommendation  or 
summary  of  findings  is  prepared,  along  with  a  proposed 
schedule  for  implementation. 

Finalize  Feasibility  Study 

When  prepared  objectively  and  with  adequate 
information,  the  feasibility  study  will  provide 
management  with  the  necessary  data  to  make  a  decision 
as  to  the  proposed  recommendation. 
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2.9  PROJECT  INITIATION  BIANAGEBiENT  DECBIONS 

At  the  conclusion  of  the  feasibility  study  and  cost  analysis,  the  ADP 
manager  presents  study  results  to  top  management  for  decisions.  If  there 
is  no  feasible  alternative  to  resolve  the  agency  data  processing  problem 
other  than  software  conversion,  management  will  likely  be  faced  with 
another  large  issue:  hardware  replacement. 

Once  the  software  conversion  decision  is  made,  additional 
management  decisions  are  required  to  support: 

o      Software  conversion  resources, 

o      An  extended  conversion  schedule, 

o      Authority  to  begin  the  conversion  requirements  phase, 

o      Project  fundii^. 

It  is  recommended  that  the  project  manager  present  a  decision 
brief ir^  to  top  management  and  cover  all  decision  requirements  and 
recommendations  as  an  entire  package.  This  provides  for  efficient 
transition  to  subsequent  software  conversion  phases. 

If  software  conversion  is  not  selected  as  a  feasible  alternative, 
project  personnnel  revert  to  normal  operational  roles.  Care  should  be 
taken  to  preserve  the  results  of  all  project  initiation  phase,  statistical 
data  and  study  results  since  this  will  prove  useful  in  any  future  conversion 
planning. 

2.10  ECONOMIC  CONSIDERATIONS 

During  the  project  initiation  phase,  personnel  will  be  the 
largest  cost  component.  Included  in  this  cost  could  be  significant 
expenses  required  for  establi^ing  the  project  team  including  new  hire  or 
relocation  expenses,  initial  project  training  courses,  and  office  set-up 
expenses. 

The  software  conversion  cost  methodology  described  in 
Appendix  C  should  be  initiated  during  this  phase.  A  cost  structure  should 
be  developed  that  represents  the  characteristics  of  the  environment  being 
costed  and  contain  a  level  of  detail  that  is  sufficient  to  provide  cost 
information  for  management  use  in  the  succeeding  phases.  The  cost 
estimates  developed  during  this  phase  will  be  based  on  summary  levels  of 
cost  detail  and  may  be  provided  through  the  use  of  software  conversion 
cost  estimation  models,  two  of  which  are  described  in  Appendix  C. 

2.11  PROJECT  INITIATION  MANAGEMENT  CHECKUST 

o       Appointment  of  full  time  project  manager 
o      Charter  approved  by  top  management 
o       Ongoing  project  costs  tracked 
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Project  team  established 

Top  management  and  information  system  user  interfaces 
established 

Interface  with  hardware  acquisition  project  members 
established 

Project  reporting  and  project  controls  established 

Regular  reporting  in  progress 
History  log  established 
Planning  aids  selected  and  used 

Impact  of  Related  Studies  Determined 

A-76 

A-109 

Other 

Applicable  acquisition  and  procurement,  policy 
regulations  and  directives  that  affect  software 
conversion  identified  and  reviewed 

Hardware  inventory  conducted 

System  software  inventory  conducted 

Data  files  inventoried 

Preliminary  workloads  estimated 

Conversion  resources  (personnel)  estimated 

Cost  methodology  developed 

Project  costs  tracked 

Feasibility  study  and  cost  analysis  conducted 

Management  decision  to  proceed/not  proceed  with 
conversion 

Reorient  efforts  to  proceed  to  next  conversion 
phase 

Plan  for  and  pursue  efforts  to  accomplish  other 
alternative(s) 
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SECTION  3 


CONVERSION  REQUIREMENTS  PHASE 

The  conversion  requirements  phase  results  in  detailed 
identification  and  assessment  of  the  scope,  requirements,  and 
complexities  of  the  conversion  effort.  This  phase  is  the  transition 
between  "what"  is  to  be  done  (project  initiation)  and  "how"  it  is  to  be 
accomplished  (conversion  planning). 

Once  the  decision  to  convert  has  been  made,  the  conversion 
project  team  must  identify  all  of  the  details  necessary  to  plan  and 
execute  the  conversion.  This  requires  an  analysis  of  the  current 
environment  to  include  identifying  feasible  alternatives  to  various 
conversion  processes  and  activities.  Management  decisions  can  then  be 
made  to  choose  the  most  cost  effective  method  of  accompli^ing  the 
conversion  activities.  In  addition  to  the  planning  details,  during  the 
requirements  phase  a  software  conversion  study  is  required  to  determine 
if  the  users  needs  are  met  at  the  lowest  overall  cost  (13). 

During  the  conversion  requirements  phase,  the  hardware 
procurement  activities  are  interrelated  and  dependent  on  software 
conversion  activities.  For  example,  workload  analysis  is  used  to 
determine  the  magnitude  of  the  software  conversion  project.  Workload 
analysis  also  serves  to  help  size  the  target  hardware  needs.  Most 
importantly,  the  software  conversion  study,  with  its  supporting  cost 
analyses  can  identify  procurement  options  which  differ  considerably  in 
cost  and  time  to  implement.  The  software  conversion  study  should 
address  conversion  to  code-compatible  as  well  as  none  ode-compatible 
hardware  and  the  respective  costs  and  operational  impacts  carefully 
developed.  Code-compatible  conversions  are  usually  much  less  costly  and 
disruptive  to  agency  operations.  While  approval  of  code-compatible 
)  conversions  cannot  be  guaranteed  due  to  Federal  competetive 
procurement  policies,  the  likelihood  is  improved  if  code-compatible 
conversion  hardware  procurement  requests  are  supported  by  reliable  and 
thorough  cost  analyses. 

3.1  REQUIREMENTS  PHASE  OBJECTIVES 

The  primary  objective  of  this  phase  is  to  provide  the 
information  necessary  to  accomplish  detailed  conversion  planning.  An 
additional  objective  of  this  phase  is  accomplishment  of  a  software 
conversion  study  which,  in  turn,  supports  preparation  and  submission  of  an 
Agency  Procurement  Request  (APR)  to  the  General  Services 
Administration. 
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3^ 


CONVERSION  REQUIREMENTS  ACTIVITIES 


The  following  conversion  requests  phase  activities  (shown  in 
Figure  3-1)  must  be  conducted: 


o  Project  team  staffing  and  organization, 

o  Application  systems  and  programs  inventory  extension 
and  assessment, 

o  Data  file  inventory  extension  and  assessment, 

o  Conversion  tool  identification  and  selection, 

o  Workload  estimation  and  refinement, 

o  Distributed  and  teleprocessing  requirements  definition, 

o  Systems  software  requirements  definition, 

o  Personnel  requirements  definition, 

o  Security  requirements  definition, 

o  Conversion  facilities  requirements  definition, 

o  Software  conversion  study  preparation. 


The  full-time  project  manager  appointed  during  project 


initiation  will  continue  to  manage  the  conversion  project  during  the 
requirements  phase.  The  project  team  requires  systems  analysis  skills 
and  planning  experience  to  develop  requirements;  the  same  skill  base 
needed  for  project  initiation.  Since  requirements  definition  and 
development  of  the  software  conversion  study  are  analogous  to  activities 
in  project  initiation,  the  same  team  members  should  be  adequate  except 
for  very  large  conversions.  As  a  guideline  however  the  following  table  is 
offered  to  aid  in  team  staffing: 
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PROJECT  TEAM  STAFFING  AND  ORGANIZATION 


3.3.1 


PROJECT  TEAM  STAFFING 


Lines  of  Code 
To  be  Converted 


Team  Size 


Less  than  100  K 
100  K  to  500  K 
over  500  K 


1-2 
4-5 
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TEAM  STAFFING  &  ORGANIZATION 

APPLICATION  SYSTEMS  INVENTORY 

DATA  FILE  INVENTORY 

CONVERSION  TOOL  SELECTION 

WORKLOAD  ESTIMATION 

TELEPROCESSING  REQUIREMENTS  DEFINITION 

SYSTEMS  SOFTWARE  REQUIREMENTS  DEFINITION 

PERSONNEL  REQUIREMENTS  DEFINITION 

SECURITY  REQUIREMENTS  DEFINITION 

FACILITY  REQUIREMENTS  DEFINITION 

SOFTWARE  CONVERSION  STUDY  PREPARATION 

▼ 

MANAGEMENT  DECISION  T 

CONVERSION  REQUIREMENTS  PHASE  ACTIVITIES 
Figure  3-1 
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These  figures  are  derived,  in  part,  from  an  Army  estimate  (39) 
and  from  case  studies  described  in  Appendix  D. 

During  the  requirements  phase  the  project  team  might  be 
augmented  by  consultants,  by  guidance  provided  by  the  Institute  for 
Computer  Sciences  and  Technology  (ICST),  or  by  support  from  the  Federal 
Conversion  Support  Center*  to  assist  in  developing  special  requirements 
such  as  security  and  teleprocessing  or  to  accomplish  the  software 
conversion  study. 

3.3.2  TURNOVER  CONSIDERATIONS 

A  key  issue  that  management  should  anticipate,  and  plan  for, 
is  personnel  turnover.  The  longer  the  project,  the  higher  the  turnover 
rate.  According  to  Tripp  and  Wahi  (34),  multi-year  projects  should  plan  for 
up  to  25%  turnover  in  staff  per  year.  The  implications  of  this  apply  to 
lengthy  requirements  phases  as  well  as  entire  conversion  projects. 
Managers  must  be  prepared  to  replace  project  team  personnel  and  possibly 
project  managers. 

Problems  in  turnover  may  be  reduced  by  team  organization 
and  assignment  of  duties.  Primary  responsibilities  for  conversion 
requirements  can  be  assigned  to  individual  team  members.  Other  team 
members  should  be  assigned  secondary  or  back-up  responsibilities.  If  one 
member  leaves  unexpectedly,  the  corporate  project  memory  is  not  lost. 

Regularly  conducted  project  discussions  and  reviews  to  keep 
all  team  members  apprised  of  project  status  also  contribute  significantly 
to  reducir^  the  effect  of  project  team  personnel  losses. 

3.4  APPLICATION    SYSTEMS    AND    PROGRAMS  INVENTORY 

EXTENSION 

The  purpose  of  this  activity  is  to  extend  the  application 
system  and  project  inventory  conducted  during  the  project  initiation  phase. 
The  details  of  the  systems  and  programs  in  terms  of  complexity  and 
construction  are  added  to  the  inventory. 

This  inventory  will  also  identify  specific  systems  and  programs 
to  be  converted  or  dropped.  The  inventory  will  permit  the  project  team 
to  group  and  assess  the  agency  application  software  inventory  from 
various  perspectives.  For  example,  the  inventory  can  be  considered  from 
a  standpoint  of  complexity,  applicable  conversion  technique  (e.g., 
automated  tool,  line-for-line  coding,  etc.),  or  lar^age.  Estimating  of 

Federal  Conversion  Support  Center 
Software  Development  Office 
General  Services  Administration 
Two  Skyline  Place,  Suite  1100 
Falls  Church,  Virginia  22041 
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levels  of  effort  and  identification  of  the  best  techniques  to  accomplish 
ct^nversion  are  considerably  aided  by  this  inventory.  Additionally,  the 
project  team  will  develop  insight  into  many  potential  conversion  problems 
and  means  to  accomplish  problem  resolution. 

Catalog  worksheets  printed  on  large  paper  will  assist  the 
project  team  in  inventorying  and  assessing  application  software.  For  very 
large  conversions  it  is  recommended  that  this  worksheet  be  automated. 
Automation  will  assist  the  project  team  in  easily  analyzir^  the  software 
inventory  from  various  aggregate  perspectives  (e.g.  language,  lines  of 
code,  environment,  or  complexity).  The  following  information 
corresponds  to  a  suggested  worksheet  (Figure  3-2)  developed  from  Federal 
sources  (39,  47).  It  should  be  modified  according  to  specific  agency  needs. 

o  PROGRAM  ID;  Specify  a  unique  identifier  for  each 
prc^ram. 

o  SOURCE  LANGUAGE  &  VERSION;  Specify  the  pro- 
gramming language  and  version  in  which  the  current 
program  is  written. 

o  LINES  OF  CODE;  Enter  the  number  of  lines  of  code  in 
the  program.  Indicate  number  of  vendor  extensions,  if 
known. 

o  MODULES  AND  EXTERNAL  CALLS;  Specify  the 
number  of  segments,  calls  to  external  subroutines,  and 
macros  which  are  copied. 


o  COMMUNICATION  INTERFACES;  If  the  program  inter- 
faces with  communication  drivers  or  special  telecom- 
munication interfaces,  indicate  interface  name  and 
function,  e.g.,  3270  protocol/ screen  format. 

o  SOURCE  PROCESSING  ENVIRONMENT;  Specify  the 
mode  of  processing  such  as  batch,  remote  job  entry 
(RJE),  interactive,  or  real-time  for  the  source  program. 

o  FILES;  Specify  the  name  and  number  of  input,  output  and 
input/output  files  processed  by  this  program.  Temporary 
files  should  not  be  included. 

o  DOCUMENTATION;  Indicate  the  level  of  documentation 
available  for  this  program  using  the  foUowir^  codes; 
0  =  None  available;  1  =  Insufficient  for  conversion; 
2  =  Satisfactory. 

o  COMPLEXITY;  Specify  the  code  that  best  reflects  the 
level  of  prc^ram  complexity.  Refer  to  Figure  -3. 

o  TARGET  LANGUAGE  AND  VERSION;  Specify  expected 
language  and  version  if  target  hardware  is  known. 
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Complexity  Factors 

A 

B 

C 

D 

Language 

ANSI  FORT., 
ANSI  PLI, 
ANSI  BASIC 

COBOL 
BASIC,  other 
high  level 

High  Level 

w/some 
Assembler 

Assembly 

Structured  Design 

Extensive 

Moderate 

Some 

None 

Lines  of  Code 

Less  than 
500 

500- 999 

999  -2K 

Over  2K 

Number  of  External 
Calls  Used 

Less  than  4 

4-8 

9-15 

Over  15 

Number  of  Segmentation 
Overlap  Routines 

Less  than  5 

5-9 

10-20 

Over  20 

Operating  Environment 

Batch 

Batch  with 
RJE 

On-Line 

^eal-time 

Embedded  Documentation 

Extensive 

Moderate 

Some 

None 

Access  Method 

Sequential 

Index  Seq. 

Direct  Access 

Other 

Number  of  Data  Files 

Less  than  5 

5-7 

8-1  1 

Over  1  1 

No.  of  Control  Stream 
Language  Statements 

Less  than  5 

5-10 

1  1-25 

Over  25 

Number  of  Utilities  to 
be  Converted 

Less  than  3 

3-5 

6-10 

Over  10 

Complexity  Code 
A+B+C+D 

//   X  1  = 
A  = 

X    X  2  = 
B  = 

//    X  3  = 
C  = 

#   X4  = 
D  = 

LEGEND 

up  to  \k                                    Simple  (1 ) 
15  to  24                                     Average  (2) 
25  to  30                                    Complex  (3) 
31  to  40                                    Verv  Complex  (4) 

COMPLEXITY  TABLE 
Figure  3-3 
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o  TARGET  PROCESSING  ENVIRONMENT;  Indicate 
whether  the  target  program  processing  environment  will 
be  batch,  remote  job  entry  (RJE),  interactive,  or  real- 
time. 

o  COMMENTS;  Enter  any  comments  or  information  such 
as  justification,  primary  user  contact,  regulatory  author- 
ization, etc.  If  one  or  more  automated  tooKs)  is 
applicable,  enter  name  of  package,  if  known. 

o  CONVERSION  STATUS;  Indicate  the  action  to  be  taken 
for      this     program.  C  =  Convert;      P  =  Purge; 

R  =  Redevelop. 

Other  statistics  which  should  be  summarized  for  the  entire 
conversion  effort  include: 

o       Total  number  of  programs  by  application  system, 

o  The  total  number  of  lines  of  job  stream  language  by 
application  system, 

o       The  number  of  job  streams  by  application  system, 

o  Major  systems  applications  by  complexity,  e.g.,  payroll, 
financial,  personnel 

3.5  DATA  FILES  INVENTORY  EXTENSION  AND  ASSESSMENT 

Although  this  activity  ^ould  have  been  completed  in  project 
initiation,  it  is  of  sufficient  importance  to  conduct  a  review  (and 
refinement  where  necessary)  prior  to  use  in  the  software  conversion 
study. 

In  particular  this  activity  should  concentrate  on  a  reexam- 
ination and  assessment  of  the  data  files  in  terms  of  determining  if  they 
can  be  converted  as  is,  converted  with  minor  changes,  or  require  a  major 
conversion  due  to  architectural  incompatibilities.  One  of  the  major 
technical  management  considerations  in  assessing  file  conversion 
requirement  is  knowing  and  understanding  the  differences  in  data 
conventions  (e  g.,  XS3,  ASCII,  EBCDIC,  BCD).  Other  items  which  must  be 
addressed  as  file  requirements  definitions  include  the  collating  sequences 
of  the  different  character  sets  and  the  internal  character  representation 
such  as  packed  decimal,  hexadecimal,  or  octaL  The  implications  with 
respect  to  sorting,  file  maintenance,  and  their  effect  on  report  listings 
are  well  known. 

File  inventory  information  may  also  be  used  to  determine  the 
priority  or  order  of  programs  to  be  converted  within  a  system  and,  to  a 
greater  or  lesser  extent,  the  order  of  systems  depending  upon  file 
interrelationships  and  interdependencies  between  programs  and  appli- 
cation systems. 
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Using  the  sample  file  worksheet  (39,  47)  (shown  in  Figure  3-4), 
the  following  information  should  be  included  in  the  inventory: 


o       FILE  ID;  Specify  a  unique  identifier  for  each  file. 

o       FILE  MEDIUM;     Indicate  the  storage  medium,  e.g., 
9 -track  tape,  removable  disk,  high  speed  drum. 

o       CODE  TYPE;    Select  the  appropriate  code  to  indicate 
the  code  data  is  currently  stored  in: 

1  =  ASCII  5  =  Binary 

2  =  EBCDIC  6  =  Packed  decimal 

3  =  BCD  7  =  Floatingpoint 

4  =  XS3  8  =  Bit  level 

9  =  Other 


o  NUMBER  OF  VOLUMES;  Indicate  if  more  than  one  tape 
reel  or  disk  pack  is  required  for  this  file. 

o  ACCESS  METHOD;  Identify  the  appropriate  file  either 
sequential,  direct  access,  or  index  sequential, 
organization  which  applies.  If  none  of  these  file 
organization  techniques  are  applicable,  specify  the  type 
of  organization  used. 

o  RECORD  FORMAT;  Specify  whether  the  record  format 
is  "FIXED,"  "VARIABLE,"  or  "OTHER."  If  "OTHER," 
describe  under  COMMENTS. 


o  RECORD  SIZE;  Specify  the  size  (in  characters)  for  each 
file  (use  one  line  for  each  record  type).  Enter  the 
number  of  records  for  each  record  format  in  the  file. 


o  BLOCK  SIZE;  Specify  the  size  (in  characters)  for  length 
of  the  record  block  size.  If  file  is  unblocked,  enter 
record  size. 

o  SECURITY /PRIVACY;  Indicate  whether  special  proce- 
dures will  be  necessary  to  protect  the  contents  of  the 
file  or  to  limit  read/write  access  to  the  file  or  parts  of 
the  file.  Indicate  whether  "R"  -  Read  or  "W"  -  Write 
restrictions  apply  to  the  file. 

o  COMMENTS;  (optional).  Enter  any  comments  or  addi- 
tional information  about  the  file.  Use  this  column  to 
further  describe  RECORD  FORMAT  (if  necessary)  or 
applicable  automated  tools,  if  known. 

o  CONVERSION  STATUS;  Indicate  the  action  to  be  taken 
for  this  file.  C  =  Convert;  P  =  Pui^e,  R  =  Redevelop. 
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The  file  inventory  data  should  then  be  summarized  by  access 
method  with  the  followir^  information  provided  for  each  method: 

o       File  medium,  e.g.,  disk,  tape  or  card, 

o       Total  number  of  files, 

o       Total  number  of  characters, 

o       Percentage  of  the  total  number  of  files  which  have  data 
stored  by  code  type, 

o       Percentage  of  the  total  number  of  files  which  have  fixed 
and  variable  length  records, 

0       Percentage  of  the  total  number  of  files  which  require 
privacy  or  security  protection. 

As  with  the  applications  and  programs  inventory,  automation 
of  the  file  inventory  for  very  large  conversions  will  help  summarizing  and 
analyzing  file  conversion  parameters  as  they  affect  conversion 
requirements. 

3.6  CONVERSION  TOOLS  IDENTIFICATION  AND  SELECTION 

Once  the  application  systems  program  and  file  inventories 
have  been  completed  and  associated  with  an  appropriate  conversion 
technique,  review  of  suitable  and  available  automated  tools  should  begin. 
Most  agencies  have  some  resident  conversion  tools.  However,  the 
screening  should  be  expanded  beyond  this  base.  A  reference  of  particular 
usefulness  is  the  Federal  Conversion  Support  Center  Conversion 
Products/Aids  Survey  (46). 

)    3.6.1  TYPES  OF  TOOLS 

For  the  purpose  of  this  guide,  three  basic  types  of  automated 
tools  are  addressed: 

o  Translators 

Translation  is  the  process  of  automatically  converting 
computer  programs  from  one  language  to  another  or 
from  one  hardware  configuration  to  another.  It  is  rare 
that  100%  translation  is  achieved,  and  inevitably  manual 
final  adjustment  is  required. 
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o  Emulators 


It  may  not  be  practical  to  convert  a  program  if  a  total 
redesign  was  planned  immediately  following  a  conversion 
or  conversely,  convert  a  program  that  will  be  terminated 
in  the  not  too  distant  future.  Operating  the  old 
programs  using  an  emulator  feature  or  package  to 
represent  the  source  machine  on  the  target  machine  may 
offer  a  feasible  alternative.  However,  other  factors 
such  as  possibly  degraded  performance  need  to  be  taken 
into  consideration  before  a  decision  is  made  to  emulate. 

o       Conversion  Aids 

This  category  encompasses  all  other  types  of  automated 
tools.  These  include  file  converters,  test  data 
generators,  source  program  directories,  optimization 
routines,  standardization  auditors,  operating  system 
converters,  operation  control  stream  language 
conversion,  flow  charting  aids  and  benchmark 
generators. 

3.6.2  SELECTION  AND  OPTIMIZATION 

Feasibility  study  techniques  should  be  used  to  select  tools. 
For  example,  manipulation  of  program  and  file  inventories  will  reveal 
areas  where  tools  may  be  feasibly  used.  Alternative  tools  can  be 
compared  with  manual  methods  and  costed  to  determine  the  most 
effective  approach. 

Each  tool  has  its  inherent  advantages  and  disadvantages 
depending  upon  the  circumstances  and  environment  involved.  Moreover, 
it  should  be  recognized  that  selection  and  implementation  of  any  of  these 
tools  is  but  a  part  of  the  conversion  effort.  Use  of  these  tools  can 
enhance  the  actual  program  and  file  conversion  effort,  but  they  will  not 
produce  completely  automated  conversion.  Some  form  of  additional 
manual  effort  is  required  for  efficient  program  and  file  operation  on  the 
source  system.  The  need  for  this  manual  effort,  and  related  costs,  have 
to  be  considered  when  analyzing  use  of  automated  tools.  Unless  other 
estimates  are  known,  estimate  20%  manual  effort  —  80%  automated  tool. 

Case  study  research  associated  with  this  guide  uncovered  one 
automated  conversion  where  the  target  system  consumed  20  hours  of  run 
time  compared  to  three  hours  execution  time  on  the  source  system.  This 
is  an  extreme  example  but  it  illustrates  that  subjective  human  judgement 
of  conversion  results  and  manual  refinement  of  application  programs 
converted  with  automated  tools  are  necessary  to  optimize  and  fine-tune 
converted  software. 
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3.6.3 


CONVERSION  TOOL  EVALUATION  FACTORS 


Candidate  conversion  tools  ^ould  be  weighed  against  the 
following  considerations: 

o  Availability 

Establish  whether  the  tool  is  a  well  established  "off-the- 
shelf"  package  or  a  new  but  untested  one;  determine 
whether  it  should  be  leased  or  purchased;  determine  how 
soon  it  can  be  delivered. 

o  Documentation 

Determine  if  the  package  is  fully  documented;  if 
documentation  includes  updates  and  revisions. 

o  Support 

Ascertain  if  the  vendor  will  stand  behind  the  product; 
determine  the  history  of  the  vendor  and  the  package; 
judge  whether  the  in-house  staff  can  handle  the  package. 

o       Operating  Efficiencies  and  Costs 

Compare  the  tool  to  other  similar  tools  in  terms  of 
purchase  or  lease  cost,  maintenance  fees  and  support 
availability,  hardware  resources  required,  operator 
training  required,  and  the  availability  and  cost  of  such 
training.  In  terms  of  performance  determine  how  the 
converted  program(s)  compare  to  the  source  program. 
Identify  past  users  to  verify  this  performance,  and 
determine  if  the  vendor  would  adhere  to  such  perfor- 
mance claims  in  a  contract. 

o       Agency  Needs 

Any  particular  considerations  that  apply  to  an  agency. 
For  example,  will  agency  hardware  handle  the  tools 
being  considered. 

The  Federal  Conversion  Support  Center  or  contractors  can 
assist  in  selection  of  automated  tool(s)  should  resources,  time,  or 
experience  preclude  an  in-house  effort. 
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3.7  WORKLOAD  ESTIMATION  REFINEMENT 


The  aggregate  workload  analysis  conducted  during  project 
initiation  should  be  further  refined.  This  will  require  an  in-depth  analysis 
of  not  only  production  workloads  but  expected  systems'  enhancements  and 
new  systems'  developments  that  will  place  a  demand  on  the  target 
hardware. 

The  associated  hardware  capabilities,  operating  systems,  and 
communication  requirements  complete  this  analysis.  Factoring  in 
historical  workload  and  projected  user's  requirements,  future  workload 
requirements  can  be  extrapolated  and  summarized.  This  workload  profile 
can  then  be  analyzed  as  a  complete,  integrated  entity.  The  profile 
picture  will  depict  the  operational  environment  that  must  be  accom- 
modated by  the  target  system. 

3.7.1  WORKLOAD  PARAMETERS 

The  most  common  information  (40)  used  to  determine 
workload  are  itemized  below.  Utilizing  hard  ware/soft  ware  monitors  (e.g., 
PLAN/4,  TSOMON,  etc.)  facilitates  obtaining  the  raw  workload  data. 

o       JOBS  PROCESSED  -  Number  of  batch  jobs  started. 

o       TRANSACTIONS    PROCESSED   -   Number   of  on-line 
transactions  processed. 

o       CPU  TIME  -  Number  of  hours  of  total  program 
CPU  time  (both  batch  and  on-line). 

o       DISK  EXCP  -  1/0  executions  for  all  direct  access 
devices,  in  thousands. 

o       TAPE  EXCP  -  I/O  executions  for  all  magnetic  tape 
devices,  in  thousands. 

o       LOCAL  PRINT  -  Number  of  lines  spooled  for  local  print, 
in  thousands. 

o       REMOTE  PRINT  -  Number  of  lines  spooled  for  remote 
print,  in  thousands. 

o       CONNECT  TIME  -  Connect  hours  for  terminals  and  RJE. 

o       TAPE  MOUNTS  -  Number  of  tape  mounts,  in  thousands. 

After  investigating  the  make-up  of  the  jobs,  transactions  and 
connect  times  (if  any),  an  analysis  can  be  made  of  the  effect  of  this 
workload  on  the  system.  Equipment  resource  utilization  is  a  measure  of 
work  units  needed  to  process  the  current  workload  on  the  source  system. 
The  main  descriptive  data  elements  for  measuring  resources  used  are  CPU 
time,  jobs  processed,  disk  EXCEPS  top  EXCPS,  and  print  volume.  An 
additional  element  describing  percent  CPU  busy  time  should  also  be 
included  since  it  is  a  key  indicator  of  maximum  resource  utilization. 
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3.7.2 


WORKLOAD  ESTIMATION 


While  numbers  of  jobs,  EXCPs  and  print  volumes  are  useful 
data  in  the  workload  analysis,  they  provide  no  yardstick  to  determine  the 
total  workload.  The  mere  fact  that  401,053  batch  jobs  have  been  run  in 
the  past  12  months  does  not  provide  much  insight  into  workload  levels. 
Further,  to  state  that  this  represents  a  monthly  average  of  50,088  or  an 
approximate  1,670  jobs  per  day  or  70  jobs  per  hour,  does  not  measure  the 
demands  on  the  system.  The  same  logic  holds  true  for  EXCPS  and  print 
volume.  What  is  important  are  processing  demands  per  hour  in  the  day 
and  hours  for  each  shift.  These  demands  are  further  influenced  by 
systems  down  time  and  systems  and  application  programming  hours  that 
must  run  in  unbroken  sequences.  Resources  should  be  examined  closely 
with  the  view  in  mind  of  ascertaining  where  and  when  saturation  occurs. 

3.8  DISTRIBUTION    AND    TELEPROCESSING  REQUIREMENTS 
DEFINITION 

Because  of  evolving  technology  the  hardware  environment  will 
likely  change  during  conversion.  While  from  an  information  system  user's 
standpoint  automated  support  remains  the  same,  changes  may  be  planned 
in  the  hardware  configuration.  The  agency  may  be  considering  central- 
ization of  multiple  site  processing  or  distributing  currently  centralized 
processing.  These  potential  changes  in  the  hardware  environment  and  the 
related  teleprocessing  requirements  have  to  be  assessed. 

The  systems  and  applications  and  data  file  inventories  identify 
distributed  and  teleprocessing  requirements  for  the  source  system.  The 
workload  analysis  identifies  gross  processing  requirements.  An  analysis 
should  be  made  of  the  processing  requirements  for  hardware  configuration 
alternatives  being  considered  by  the  agency.  If  the  staff  involved  in 
hardware  procurement  do  not  accomplish  this  analysis,  it  must  be  done  by 
the  software  conversion  staff. 

Each  conceptual  hardware  configuration  should  be  analyzed 
with  respect  to  software  processing  requirements.  This  accomplishes  a 
number  of  purposes: 

o       It  assists  in  verifying  that  considered  hardware  configur- 
ations are  feasible, 
o       It  improves  the  specificity  of  the  hardware  RFP, 
o       It  identifies  distributed,  multiple  site,  and  teleprocessing 
software  requirements. 

3.9  SYSTEM'S  SOFTWARE  REQUIREMENTS  DEFINITION 

Requirements  have  to  be  developed  for  systems  software 
which  support  applications  software  and  data  files.  Included  are 
compilers,  spooling,  utilities  and  hardware  monitoring  packages. 
Requirements  should  be  developed  as  mandatory  or  desirable  by  the 
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project  team.  This  serves  two  purposes:  It  assists  developing  the 
hardware  procurement  RFP  and  in  software  conversion  planning.  Early  in 
the  planning  phase  the  hardware  configuration  will  be  unknown.  Planners 
must  be  cognizant  of  systems  software  that  they  can  be  assured  of  and 
that  which  may  or  may  not  be  supplied  by  the  hardware  vendor. 

3.10  PERSONNEL  REQUIREMENTS  DEFINITION 

Application  system  and  program,  file,  conversion  tool  and 
teleprocessing  requirements  will  be  used  by  the  project  manager  to 
identify  the  conversion  resource  requirements. 

In  assessing  resources  the  project  manager  must  weigh  internal 
resources  available  against  the  total  workload  to  determine  the  adequacy 
of  the  in-house  staff.  Once  the  initial  level  of  effort  is  estimated  and 
outside  resources  (i.e.  contractor  assistance)  is  deemed  necessary,  cost 
effective  determinations  will  have  to  be  made  regarding  where  to  apply 
external  assistance  (i.e.  planning  preparation,  conversion,  etc.) 

Finally,  if  preliminary  requirements  indicate  need  for  outside 
assistance,  requirements  should  be  developed  for  the  RFP  for  software 
conversion  assistance  (e.g.  type  of  procurement,  deliverables,  milestones, 
duration,  etc.)  which  will  be  prepared  in  the  conversion  preparation  phase. 

3.11  SECURITY  REQUIREMENTS  DEFINITION 

Security  and  privacy  are  often  overlooked  during  software 
conversion.  A  project  team  review  of  all  agency  information  systems  for 
agency  and  Federal  security  and  privacy  requirements  will  assist  in 
engineering  security  features  into  sensitive  software  data  files  and 
software  processing  during  conversion  and  avoid  costly  modification  later. 

The  basic  Federal  security  requirements  are  contained  in  the 
Office  of  Management  and  Budget  (OMB)  Circular  A-71,  Transmittal 
Memorandum  No  1,  Security  of  Federal  Automated  Information  Systems 
(July  1978).  In  general  this  regulation  requires  design  and  approval  of 
agency  software  of  security  specifications,  security  design  reviews  and 
security  testing  to  comply  with  A-71  or  other  applicable  Federal  policies 
(e.g.,  DOD  security  regulations).  These  policies  are  pertinent  to  software 
conversion.  If  software  support  is  to  be  acquired  commercially,  either  as 
general  purpose  packages  or  converted  by  a  contractor,  security 
specifications  have  to  be  developed.  Additionally,  a  risk  analysis  is 
required  whenever  an  agency  undergoes  a  significant  software  change. 
Agency  software  security  requirements  have  to  be  compared  with  this  risk 
analysis.  The  project  manager  should  enlist  the  support  of  the 
information  system  users  and  the  agency  information  system's  security 
officer  in  developing  security  conversion  requirements.  If  an  agency  has 
extensive  sensitive  information  systems,  assistance  from  an  outside 
information  system's  consultant  as  an  advisor  to  the  project  team  is 
recommended. 
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3.12  CONVERSION  FACILmES  REQUIREMENTS  DEFINITION 

3.12.1         CONVERSION  PROCESSING  FACILITIES 


The  requirements  of  accomplishing  software  conversion  on 
systems  running  production  applications  have  to  be  developed.  This 
applies  to  conversion  associated  with  hardware  replacement  as  well  as 
conversions  that  are  not  associated  with  hardware  replacement. 

The  key  requirements  are  to  provide  conversion  processing 
time  and  convenient  and  nondisruptive  hardware  systems  access, 
regardless  of  whether  it  is  source  or  target,  and  nondisruptive  production 
support  to  information  system's  users.  Note:  If  sensitive  processing  is 
accomplished  on  agency  computers,  security  must  be  carefully  considered 
for  all  alternatives  considered. 

Any  use  of  excess  capacity  on  a  source  target  computer  for 
conversion  will  likely  be  cost  effective.  Additional  advantages  include 
convenient  location  and  conversion  team  familiarity  with  the  source 
system  Disadvantages  could  include  inconvenient  access  time.  Final 
determination  of  conversion  processing  facilities  will  depend  upon  a 
requirements  analysis  to  determine  if  additional  operators  have  to  be 
hired  and  if  production  schedules  can  be  adjusted  to  provide  time 
convenient  to  the  conversion  project  team.  Otherwise,  alternative 
choices  such  as  commercial  time  sharing,  use  of  leased,  off  site, 
production  facilities,  or  use  of  surplus  capacity  at  another  government 
agency  should  be  investigated. 

If  software  conversion  activities  must  be  accomplished  on  the 
same  system  used  for  production  and  there  are  no  feasible,  cost  effective 
alternatives  for  avoiding  contention  between  production  and  conversion 
activities,  negative  impacts  must  be  minimized  The  project  manager 
should  consider: 

o  Reexamination  of  application  systems  to  determine  if 
some  unnecessary  systems  have  been  overlooked  and  can 
be  eliminated  to  provide  for  additional  processing  time, 

o  Soliciting  the  cooperation  of  information  system  users 
and  agency  executives  to  determine  if  some  information 
systems  degradation  can  be  accepted, 

o  Examining  information  systems  to  determine  if 
modifications  can  produce  required  information  with  less 
processing. 

The  key  management  issues  here  are  achieving  cooperation 
and  support  by  users  and  top  managers  and  havir^  sufficient  time  to 
explore  alternatives  to  any  possible  hardware  contention  problems.  If 
contention  is  not  resolved,  the  project  manager  can  expect  slippage  in  the 
conversion  and  inefficient  use  of  project  team  resources. 
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3.12.2 


CONVERSION  TEAM  FACILITIES 


Conversion  resource  assessments  will  result  in  estimates  of 
the  conversion  team  size,  the  extent  of  contractual  effort,  and  whether 
contractors  should  be  located  at  the  agency  or  their  own  facilities. 
Conversion  team  facility  requirements  can  then  be  developed. 

3.13  SOFTWARE  CONVERBON  STUDY  PREPARATION 

The  culmination  of  this  phase  is  the  preparation  of  a  software 
conversion  study.  This  study,  mandated  by  FPMR  Regulation  F-492,  and 
amended  by  F-496,  provides  the  justification  for  the  conversion  and 
development  of  the  Agency  Procurement  Request  (ADP)  for  submission  to 
GSA  for  hardware  acquisition.  There  is  no  specific  format  presented  in 
the  software  conversion  study.  However,  it  is  recommended  that  the 
project  manager  acquire  a  conversion  study  checklist  from  the  Federal 
Conversion  Support  Center.  This  guide  is  useful  in  structuring  a  study  to 
meet  agency  requirements  and  to  insure  completeness.  In  general,  the 
study  should  include: 

o  Problems 

Describe  the  agency  ADP  problems  which  result  in  the 
need  for  hardware  replacement/software  conversion. 

o       Current  ADP  Environment 

Describe  the  existing  systems  to  provide  a  basis  for 
determining  the  economic  and  technical  advantages  of 
the  proposed  new  system  or  change.  This  description 
should  include  the  following  information: 

Equipment  -  Itemize  all  equipment  used  by  the 
existing  system. 

Software  -  Itemize  all  system  and  applications 
software  including  all  data  files. 

Other  Systems  Software  -  Identify  all  other 
software  to  include  operating  systems,  utilities 
general  purpose  software. 

Personnel  -  Identify  skill  categories  and  number  of 
personnel  required  to  operate/maintain  the  existing 
system. 
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o  Workload  Analysis  An  analysis  of  the  existing  system 
workload  should  provide  a  baseline  for  determining  trade 
offs  and  advantages  of  the  target  system.  Processing 
and  system  requirements  should  also  be  described. 

o  System  requirements  (i.e.,  the  proposed  ADPE 
Environment) 

Describe  the  requirements  and  objectives  of  the 
proposed  target  system. 

o       Procurement  Alternatives 

Describe  each  alternative  system  in  detaiL  State 
reasons  for  consideration.  Alternatives  should  include 
fully  competitive  (noncode-compatible).  Limited 
competitive  (code-compatible),  and  sole  source.  Include 
projected  procurement  schedules. 

o       Cost/Benefit  Analysis 

The  purpose  of  the  cost/benefit  analysis  is  to  provide 
management  with  adequate  cost  and  benefit  information 
to  analyze  and  evaluate  the  alternative  (target)  systems. 
Describe  the  cost  of  procurement,  training,  site 
preparation,  benchmark,  contractor  assistance  and 
conversion  for  each  alternative.  State  benefits  in 
quantifiable  terms.  Non-quantifiable  benefits  should 
address  organizational  objectives,  user's  satifaction  and 
improved  missions  and  goals.  Describe  the  risks  in  terms 
of  cost  for  each  alternative  considered. 

o       Recommendations  and  Implementation  Schedule 

State  the  reasoning  and  justification  to  support  the 
recommendation  of  the  selected  procurement  alternative 
over  the  other  alternatives  with  an  indepth  discussion  of 
cost  to  benefits.  Identify  consequences  of  not  taking 
action.  Include  a  schedule  and  milestones  for  each  major 
phase  of  the  recommended  system  and  conversion. 

3.14  REQUIREMENTS  PHASE  MANAGEMENT  DECISIONS 

At  the  conclusion  of  the  conversion  requirements  phase  the 
ADP  manager  submits  the  software  conversion  study  for  agency  executive 
approvaL  This  study  will  normally  accompany  and  be  approved  with  other 
hardware/procurement  related  actions,  primarily  the  Agency  Procurement 
Request. 


50 


Other  agency  executive  decisions  that  will  be  required  during 
the  conversion  requirements  phase  will  be  approval  and  funding  support 
from: 

o       Federal  Conversion  Support  Center, 

o       Outside  resources  which  might  be  required  to  assist  in 
security  requirements  or  the  software  conversion  study. 

3.15  COST  AND  ECONOMIC  CONSIDERATIONS 

In  the  conversion  requirements  phase,  project  personnel  costs 
will  comprise  a  significant  portion  of  operational  costs  incurred. 
Additional  areas  of  cost  which  may  be  incurred  include  consultant  fees 
such  as  security  assistance  or  in  preparing  the  software  conversion  study. 
If  operating  personnel  are  used  to  assist  in  the  software  inventory  or 
workload  analysis,  their  costs  should  be  assigned  to  the  conversion 
project- 

The  software  conversion  project  cost  estimates  developed 
during  project  initiation  will  be  refined  using  the  workload,  data  file  and 
program  data  that  is  developed.  Personnel  cost  estimates  can  be 
improved  by  using  the  actual  salaries  of  personnel  currently  assigned  to 
the  project,  and  those  proposed  in  the  future.  At  this  stage  in  the  cost 
estimation  process,  cost  may  still  be  estimated  at  a  summary  level  of 
detail,  however,  as  specific  cost  areas  can  be  identified,  (e.g.,  project 
personnel  salaries)  this  detail  should  be  incorporated  into  the  costing 
information. 

In  determining  the  conversion  requirements,  a  major  area  of 
cost  input  will  be  in  the  assessment  of  in-house  personnel  resources,  and 
the  feasibility  of  using  conversion  tools.  The  assessment  of  the  current 
staffs  ability  to  perform  the  conversion  must  address  factors  such  as  the 
availability  and  cost  of  current  staff,  potential  new  hires,  and  contractor 
personnneL  The  assessment  of  staff  adequacy  should  be  based  upon  the 
full  cost  of  the  project.  In  this  manner  the  use  of  higher  cost,  contractor 
personnel  may  be  justified  if  the  project  duration  can  be  shortened. 
Similarly,  the  feasibility  of  conversion  tools  should  address  the  full  cost 
impact  on  the  entire  project,  and  not  just  the  cost  of  completing  one  task 
in  the  project. 

Cost  input  will  also  be  required  in  the  completion  of  the 
software  conversion  study  where  the  project  budget  is  detailed  by  cost 
element,  phase,  function  and  year,  and  a  cost-effectiveness  analysis  of 
the  proposed  course  of  action  is  provided.  This  study  will  require  a  close 
coordination  between  the  cost  included  in  the  hardware  acquisition 
estimates  and  the  conversion  project  estimates  to  assure  that  all  costs  are 
reflected,  and  none  are  counted  twice. 
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REQUIREMENTS  MANAGEMENT  CHECKLIST 

0       Full-time  project  manager  continues 

o       Project    team    staffed    with   skills    for  requirements 
definition 

o       Project  briefings  to  top  management  continued 
o       Special  assistance/skills  identified 
Security 

Telecommunications 
Software  Conversion  Study 

o       Project  team  augmentation  provided 

FCSC 
Consultant 

o       Application  system  and  program  inventory  extended 
o       Data  files  inventory  extended 

o       Potential     conversion     tools     selected,  information 
requested 

o       Workloads  estimated  and  refined;  future  workloads  fully 
projected 

o       Requirements    analyzed    from    distributed  processing 
perspective 

o       Requirements  analyzed  from  teleprocessing  perspective 

o       Systems  software  requirements  developed 

o       Conversion  personnel  requirements  developed 

In-House  staff 
Contractors 

o       Security  requirements  defined 

Compared  with  new  risk  analysis 
Information  system  user  input 
Agency  information  system  office  input 
Processing  requirements  doublechecked 

o       Conversion  hardware  facilities  requirements  defined 
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Conversion  team  facilities  requests  defined 

Software  conversion  study  completed 

Code  compatible  alternative  carefully  costed 
Non-code     compatible     conversion  alternative 
carefully  costed 

Executive  approval  of  software  conversion  study 
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SECTION  4 
CONVERSION  PLANNING  PHASE 


During  the  conversion  plannir^  phase,  the  project  team  will 
develop  the  organization  and  the  schedules  to  be  followed  in  preparation 
for  and  during  the  conversion. 

Economic  considerations  associated  with  these  activities  must 
be  addressed.  The  cost  information  previously  developed  for  budget 
estimates,  cost-benefit  analyses  and  feasibility  studies  and  the  software 
conversion  study  will  become  more  refined  as  conversion  activities  are 
planned  in  more  detail.  This  information  can  support  the  preparation  of 
future  budgets  and  conversion  plans. 

The  importance  of  planning  cannot  be  overstated.  It  is,  in 
fact,  the  most  important  phase.  Proper  planning,  early  in  the  software 
conversion  process,  will  prevent  many  problems  from  occurring,  and  will 
prepare  management  for  handling  the  unforeseen  contingencies  that  may 
occur  (23,  39). 

The  case  studies  presented  in  Appendix  D  reiterate  the 
importance  of  proper  planning.  Managers  who  experienced  fairly  smooth 
conversion  efforts  had  prepared  detailed  plans,  schedules  and  milestones, 
and  tracked  performance.  On  the  other  hand,  for  those  conversions  that 
had  experienced  difficulties,  the  major  problems  could  usually  be  traced 
directly  to  inadequate  planning.  Managers,  when  queried  as  to  how  they 
could  improve  future  conversions,  emphasized  the  need  to  plan  early  and 
in  detaiL 

This  section  describes  the  activities  related  to  compiling  a 
conversion  plan.  Associated  planning  costs  can  be  developed  in 
accordance  with  the  methodology  in  Appendix  C.  The  impacts  of  this  cost 
information  on  management  decisions  are  discussed  as  they  occur. 

4.1  PLANNING  OBJECTIVES 

The  objective  of  this  phase  is  to  prepare  a  conversion  plan 
which  encompasses  aU  subordinate  plans  and  schedules  to  prepare  for  and 
complete  the  conversion.  Conversion  plan  development  requires  a 
thorough  examination  of  all  activities  that  must  occur  prior  to,  during, 
and  after  the  conversion  efforts. 

To  meet  this  objective,  the  following  results  must  be  achieved: 

o  Planning  must  be  detailed,  and  flexible, 

o  Personnel  must  be  assigned, 

o  Facilities  must  be  planned, 

o  Schedules  must  be  developed, 

o  A  reporting  hierarchy  must  be  developed, 

o  A  project  tracking  mechanism  must  be  developed. 
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4.2  DECISIONS  IMPACTING  PLANNING 


During  the  planning  phase  there  are  three  major  decision  areas 
which  have  the  most  affect  on  conversion  and  that  will  be  made  by  top 
agency  executives  or  external  organizations: 

o       Budget   decisions   by    top    management,    or  external 
organizations  (e.g.,  Office  of  Management  and  Budget), 

o       Procurement     decisions    by    external  organizations 
(e.g.,  GSA), 

o      Schedule  decisions  by  agency  executives. 

4.2.1  BUDGET 

Conversion  cost  estimates  made  during  the  project  initiation 
phase  feasibility  study  and  the  requirements  phase  software  conversion 
study  will  have  been  entered  into  agency's  budgets  and  submitted  to  OMB 
and  to  Congress  for  approval  and  appropriations.  Cost  estimates 
developed  during  the  conversion  requirements  phase  will  have  also  been 
submitted  to  GSA  for  review  and  approval  (14,  15).  The  project  manager 
should  continually  review  the  status  of  conversion  fiscal  decisions  to 
determine  if  the  conversion  is  approved  and  any  fiscal  constraints 
applicable  to  planning. 

4.2.2  PROCUREMENT 

The  conversion  planning  will  also  be  impacted  by  the  selection 
of  the  target  machine.  Cost  evaluations.  Federal  regulations  and  statutes 
(e.g.,  the  Brooks  Act)  may  require  a  competitive  procurement  (14,  15). 
This  could  result  in  selection  of  non-code  compatible  hardware,  creating  a 
more  difficult  conversion  hardware  environment. 

At  the  initial  stages  of  the  conversion  planning  phase  the 
target  hardware  will  be  unknown.  The  project  manager  must  initially 
formulate  plans  to  cover  conversion  on  both  code  compatible  and  non- 
code  compatible  target  hardware.  There  is  no  way  to  avoid  planning  for 
both  contingencies.  However,  the  software  conversion  study  completed  in 
the  requirements  phase  should  provide  insight  into  a  probable  procurement 
alternative  that  wiU  be  chosen.  If  there  are  significant  cost  savings  or 
avoidances  in  a  code  compatible  conversion,  initial  planning  emphasis  can 
be  focused  in  that  direction.  If  cost  savings  are  ambiguous,  the  most 
difficult  conversion,  non-code  compatible,  can  be  assumed. 

Sometimes  in  the  mid  to  late  stages  of  the  conversion  planning 
phase  the  target  hardware  procurement  alternative  will  be  known.  If  code 
compatible  hardware  will  be  acquired  (even  though  competitive  selection 
has  yet  to  take  place)  detailed  plans  can  be  formulated.  If  a  fully 
competitive  acquisition  is  pursued,  much  planning  will  have  to  wait  until 
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the  procurement  process  is  completed  and  the  target  hardware  is 
identified.  This  condition  often  places  pressures  to  complete  detailed 
plans  in  a  short  timeframe,  prior  to  target  hardware  installation.  The 
project  manager  has  to  anticipate  this  contingency.  It  is  extremely 
important  for  the  project  manager  to  maintain  continuing  interface  with 
the  hardware  selection  staff  to  gain  knowledge  of  hardware  selection 
decisions  as  early  as  possible. 

4.2.3  SCHEDULE  RESTRICTIONS 

The  time  frame  for  the  conversion  effort  may  be  affected  by 
management  decisions.  Contractual  arrangements  or  budget  decisions 
may  dictate  seemingly  arbitrary  installation  times  of  the  target 
equipment  or  removal  of  the  source  equipment.  To  meet  overall  agency 
needs,  management  may  require  the  conversion  to  be  completed  by  a 
certain  date.  The  software  conversion  plans  are  thus  additionally 
constrained.  Application  of  additional  agency  resources  may  have  to  be 
planned  to  meet  the  completion  schedule,  or  outside  contractors  with 
appropriate  expertise  may  have  to  be  used.  These  actions  may  affect 
operations  and/or  the  cost  of  the  conversion  effort. 

4.3  CONVERSION  PLANNING  ACTIVITIES 

Figure  4-1  illustrates  the  activities  that  occur  during  the 
software  .conversion  planning  phase.  During  this  phase  the  project 
manager  must  organize  the  project  team  for  developing  detailed  plans  for 
the  software  conversion.  Thereafter,  the  project  manager  and  project 
planning  team  will: 

o       Develop  a  staffing  plan  to  accomplish  the  software 
conversion, 

o       Develop  a  training  plan, 

o       Plan  a  conversion  schedule  and  mechanisms  to  track 
conversion  plan  execution, 

o       Plan  for  software  program  preparation, 

o       Involve    functional    users    and    top    management  in 
conversion  plans, 

o  Plan  for  use  of  conversion  hardware  facilities, 

o  Provide  for  location  of  the  conversion  team, 

o  Plan  for  documentation  of  converted  software, 

o  Plan  for  contingencies. 
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ORGANIZING  THE  PLANNING  TEAM 

STAFFING  PLANNING 

CONTRACTUAL  ASSISTANCE  PLANNING 

TRAINING  PLANNING 

SCHEDULING  AND  PROJECT  TRACKING 

SOFTWARE  PREPARATION  PLANNING 

USER  AND  EXECUTIVE  INTERFACE 

HARDWARE  FACILITY  PLANNING 

TEAM  LOCATION  PLANNING 

DOCUMENTATION  PLANNING 

CONTINGENCY  PLANNING 

SECURITY  PLANNING 

TELECOMMUNICATIONS  PLANNING 

CONVERSION  PLAN  APPROVAL 

▼ 

MANAGEMENT  DECISION  T 


CONVERSION  PLANNING  PHASE  ACTIVITIES 
Figure  4-1 
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4.4 


ORGANIZATION  OF  THE  PROJECT  TEAM  FOR  PLANNING 


Before  detailed  planning  can  begin,  personnel  who  will 
participate  in  the  planning  must  be  assigned  (47).  Project  team  staff 
members  who  participated  in  the  project  initiation  and  requirements 
phases  will  normally  continue  in  planning  roles  since  planning  requires  in- 
depth  understanding  of  the  requirements. 

Additionally  the  project  team  skills  should  be  extended  by 
augmenting  the  team  with: 

o  Systems  Programmers  to  provide  planning  details  or 
systems  processir^  impacts, 

o  Application  Programmers  who  have  insight  in  the 
construction  of  agency  information  systems, 

o  User's  Representatives  who  will  assist  in  the  conversion 
(e.g.,  durir^  parallel  testing), 

o  Operational  Personnel  who  will  also  assist  in  the 
conversion  (e.g.,  assisting  in  system  testing  planning 
schedules), 

o  Communications  Staff  to  provide  assistance  in 
teleprocessing  planning, 

o  Security  Personnel  to  assist  in  security  and  privacy 
plannir^  details. 

These  personnel  may  participate  at  different  times,  and  at 
different  levels,  but  their  planning  input  is  needed.  Where  in-house 
specialist  skills  are  lacking,  external  assistance  (e.g.,  Federal  Conversion 
Support  Center;  consultants,  etc.)  can  be  effectively  used  to  shorten 
planning  schedules  and  to  develop  more  detailed,  comprehensive  plans. 

4.5  CONVERSION  STAFFING  PLAN 

One  of  the  initial  steps  is  the  development  of  a  plan  for 
organizing  and  structuring  the  conversion  project  team,  (i.e.,  determining 
personnel  to  participate  in  the  conversion,  identifying  responsibilities  and 
developing  a  management  hierarchy). 

4.5.1  TEAM  COMPOSITION  DURING  ACTUAL  CONVERSION 

Members  of  the  project  team  during  the  conversion  phase 
should  include  (3^0: '  * 

o  Task  Leaders  -  Senior-level  personnel  with  senior  level 
analyst  and  programming  skills  at  the  leadership  level, 
preferably  with  some  conversion  experience. 
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o  Senior  Systems  Analysts/Programmers  -  Personnel  with 
senior  level  programming  skills,  preferably  with  some 
conversion  experience.  These  personnel  should  be  able 
to  assist  programmers  with  conversion  programming 
problems. 

o  Senior  Programmers  -  These  report  directly  to  their  Task 
Leaders  and  perform  the  actual  program  conversions. 

o  Operational  Personnel  -  Staff  members  responsible  for 
operation  of  source  and  target  equipment. 

o  Vendor/Contractor  Support  Personnel  -  Personnel  who 
will  train  and  assist  agency  personnel  during  the 
conversion  effort. 

The  size  of  the  conversion  project  team  is  dependent  on  the 
software  conversion  workload  estimated  during  the  conversion 
requirements  phase. 

Selection  of  personnel  is  dependent  on  a  number  of 
considerations,  including: 

o  Conversion  Experience  -  prior  conversion  experience  is 
important.  Even  if  conversion  experience  has  been  in  a 
different  hardware/software  environment,  conversion 
insight  is  valuable. 

o  Skills  -  Extensive  selection  of  entry  or  low-skill  level 
people  will  lead  to  delays,  conversion  slippage  and 
increased  costs.  For  this  reason,  many  agencies  assign 
their  most  experienced  personnel  to  conversion  duties. 
It  is  preferable  to  assign  personel  who  know  both  source 
and  target  hardware  and  languages.  If  this  is  not 
possible,  personnel  with  knowledge  of  target  hardware 
and  languages  should  get  priority. 

o  Availability 

Experience  indicates  that  personnel  assigned  to 
conversion  efforts  should  remain  on  the  project  until 
their  part  is  completed.  Plans  should  provide  that  each 
staff  member  be  dedicated  to  the  conversion  effort 
during  the  time  assigned. 

A  matrix  management  approach  can  be  applied  to  resource 
planning.  Matrix  management  can  assist  by  identifying  conversion 
personnel  skills  and  applying  them  to  conversion  tasks  with  maximum 
effectiveness.  Figure  4-2  illustrates  how  this  can  be  accomplished.  This 
also  assists  in  defining  conversion  responsibilities. 
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NAME 

APPLICATION 

SKILLS 

AVAILABILITY 

Smith 

Payroll 

COBOL, CSL 

6  months 

Jones 

Personnel 

COBOL. CSL 

6  months 

Butler 

Modeling 

FORTRAN, CSL 

2  months 

Brown 

Personnel 

COBOL 

a  months 

Green 

Personnel 

COBOL.  FORTRAN 

3  months 

Lax  kins 

Modeling 

FORTRAN 

3  months 

Donnley 

Payroll 

COBOL, CSL 

4  months 

APPLICATION 

PERSON 
MONTHS 
EFFORT 

ASSIGNMENT 

COMMENT 

Payroll 

3 

Smith  4,  Donnley  4 

Personnel 

18 

Jones6,  Brown6,  Green3.  Smith2, 

short  1 

Models 

4 

Larkins2,  Butler2. 

Larkins 
over  1 

SAMPLE  MATRIX  MANAGEMENT 
PLANNING 


Figure  4-2 
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4.5.2 


ASSIGNMENT  OF  RESPONSIBILITIES 


Plans  should  be  developed  for  assignment  of  responsibilities  to 
all  members  of  the  conversion  team.  This  will  increase  understanding  of 
conversion  duties  and  reduce  the  possibility  of  duplication  of  effort  or 
omission  of  important  conversion  tasks  at  critical  times. 

4.5.3  MANAGEMENT  HIERARCHY 

A  management  hierarchy  (see  Figure  4-3)  should  be  included 
into  the  conversion  plan  for  control  and  project  reporting. 


4.6  PLANNING  FOR  CONTRACTUAL 

ASSBTANCE/AUTOMATED  CONVERSION  TOOLS 

An  assessment  of  automated  tools  and  the  need  for 
contractual  assistance  was  made  during  the  requirements  phase. 
Decisions  to  use  automated  tools  or  to  obtain  contractual  conversion 
assistance  were  based  on  a  number  of  factors,  including: 

o      In-house  expertise, 

o       Cost  effectiveness, 

o       Internal  resource  availability, 

o       Conversion  time  frame. 

During  the  planning  phase  it  is  important  to  plan  for  the  use  of 
contractors  or  automated  tools.  Planning  details  should  specify: 

o       When  to  employ  them, 
o       Who  will  use  them, 
o       How  they  can  be  acquired, 
o       Where  to  acquire  them, 
o      Training  needs. 

The  requirements  for  and  identification  of  conversion  tools 
will  have  already  been  made  during  the  requirements  phase  using 
guidelines  such  as  those  provided  by  the  Federal  Conversion  Support 
Center  (40).  The  emphasis  will  be  on  planning  the  use  rather  than 
selection.  Final  selection  will  only  be  determined  when  the  target 
hardware  is  identified.  Likewise,  planning  details  for  employment  of 
conversion  contractors  can  only  be  made  after  target  hardware 
identification  and  full  assessment  of  the  cost  benefits  of  use  of  in-house 
resources  vis-a-vis  contractor  support  can  be  assessed. 
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AGENCY 

EXECUTIVES 


INFORMATION 
SYSTEM 

USER 


ADP 
MANAGER 


r 


PROJECT 
MANAGER 


EXTERNAL 
SUPPORT 


TASK 
LEADER 


TASK 
LEADER 


r 


STAFF 


STAFF 


I  


SAMPLE  REPORTING  HIERARCHY 
Figure  4-  3 
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4.6.1 


PLANNING  FOR  A  SOFTWARE  REQUEST  FOR  PROPOSAL 
IRFP^  ^ 


If  a  decision  was  made  to  obtain  the  services  of  a  contractor 
to  assist  during  the  conversion,  plans  have  to  address  (47): 

o  What  goes  in  the  RFP, 

o  When  it  is  to  be  issued, 

o  How  it  is  to  be  released  (i.e.,  competitive,  sole  source), 

o  Type  of  contract  (i.e.,  fixed  price,  cost  plus,  fixed  fee). 

The  experiences  of  Federal  agencies  interviewed  indicated 
that  the  following  should  be  included  in  a  software  conversion  RFP  plan: 

o       Number  of  lines  of  code  to  be  converted, 

o       Number  of  programs,  files,  applications  to  be  converted, 

o       Conversion  schedule, 

o       Average  effectiveness  level  and  efficiency  of  code, 

o  Documentation, 

o       Provision  for  test  data, 

o       Vendor  evaluation  criteria. 

Programs,  files  and  lines  of  code  are  known  from  data 
developed  during  the  requirements  phase.  Cost  is  generally  based  on  fee 
per  line  of  code  converted.  Most  agencies  contacted  in  developing  this 
guide,  that  used  an  outside  contractor,  based  their  fee  schedule  on  this 
scheme. 

It  is  important  to  plan  a  conversion  schedule  for  inclusion  in 
the  contract.  Planning  the  schedule  is  described  in  Section  4.8.  An 
agency  should  consider  including  incentives  and/or  penalty  fees  in  the 
contract.  Any  penalty  fees  should  reflect  the  total  cost  impact  to  the 
agency  of  the  increased  costs  of  continuing  current  operations  beyond  the 
scheduled  software  acceptance  date.  A  warranty  clause  may  also  be 
included.  This  clause  would  require  the  contractor  to  provide  personnel 
after  conversion  completion  for  troubleshooting  purposes. 

Agencies  commonly  specify  that  a  contractor  must  deliver 
programs  that  execute  a  certain  percentage  of  code  using  test  data  (e.g., 
70%).  This  alone  does  not  assure  production  of  efficient  or  effective 
code.  The  agency  should  consider  stating  in  the  RFP  an  average  operating 
efficiency  level  expected  for  each  program  converted.  A  number  of 
Federal  agencies  did  not  include  this  in  their  contracts,  and  they 
experienced  many  programs  running  much  longer  on  target  machines  than 
source  machines,  despite  the  fact  that  the  target  machines  had  faster 
processing  times. 

The  RFP  plan  should  also  state  what  documentation  the 
contractor  must  provide.  These  should  be  in  accordance  with  agency 
standards  or  FIPS  PUB  38  or  64. 
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Provision  of  test  data  should  be  defined  in  the  planning.  Most 
agencies  choose  to  develop  and  provide  the  data  to  test  contractually 
converted  code  since  agencies  have  the  best  insight  regarding  information 
system  processing  requirements.  If  an  agency  chooses  to  let  a  contractor 
develop  test  data,  plans  should  be  developed  for  agency  verification  prior 
to  test  data  use  and  acceptance  of  converted  software. 

Planning  should  allow  all  statement  of  work  and  evaluation 
criteria  to  be  continually  refined  up  to  the  point  of  issuances  of  the  RFP. 
Evaluation  criteria  should  be  summarized  but  developed  in  detail  so  that 
contractors  will  know  the  exact  terms  expected  for  acceptable 
performance.  In  this  regard  it  is  useful  if  RFP  plans  are  developed  in 
looseleaf  notebook  form  in  a  format  corresponding  to  a  statement  of  work 
and  evaluation  criteria.  This  will  facilitate  translation  of  plans  into 
contract  formats. 

It  is  advantageous  for  the  project  team  planning  the  use  of 
contractors  to  have  contractual  experience.  If  this  experience  is  not 
resident,  it  must  be  gained  somehow.  One  agency,  inexperienced  in 
managing  a  software  conversion  contract,  gained  experience  by  releasing 
a  preliminary,  short-term  software  conversion  RFP.  The  RFP  required 
that  the  selected  contractor  convert  one  application  system  from  the 
source  to  the  target  system.  This  small  contract  effort  served  a  number 
of  purposes.  It  surfaced  a  number  of  conversion  problems  in  converting  to 
the  target  system,  provided  the  management  team  experience  in 
conducting  a  conversion,  and  also  provided  the  experience  in  managing  a 
software  contract.  Additionally,  this  approach  produced  insight  into 
additional  performance  criteria  and  schedules  that  were  translated  into 
planning  the  major  software  RFP. 

4.6.2  CONTRACT  MONITORING 

During  the  planning  phase,  a  mechanism  should  be  developed 
for  monitoring  the  contract.  If  the  contract  is  lai^e  enough,  the  project 
manager  should  be  assigned  as,  or  have  assigned  on  the  project 
management  team,  a  full-time  Contractir^  Officer's  Technical 
Representative  (COTR). 

4.7  PLANNING  FOR  TRAINING 

A  training  schedule  for  the  project  team  as  well  as  the  entire 
software  staff  should  be  developed.  Training  itself  should  begin  and  end 
prior  to  the  conversion.  However,  if  carefully  planned,  training  can 
extend  into  the  conversion  phase.  Proper  training  of  personnel  and 
adequate  training  schedules  are  of  major  importance  in  keeping  the 
conversion  process  on  track  (33).  The  impact  of  training  conducted  too 
late  is  apparent  -  staff  is  being  trained  when  they  should  be  converting 
software.  What  is  not  well  understood  is  that  training  can  be  conducted 
prematurely.  The  time  lapse  between  training  and  conversion  degrades 
effectiveness. 
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Following  is  a  checklist  of  conversion  training  plan 
requirements.  Based  on  this  checklist,  the  project  planning  team  should 
develop  a  detailed  training  outline,  the  content  of  each  subject  area  and  a 
training  schedule.  Training  should  include  all  conversion  and  operational 
personnel,  and  functional  users.  The  project  manager  should  coordinate 
training  plan  schedules  with  all  concerned  to  ensure  that  the  content  and 
schedule  meet  agency  requirements. 

Training  Requirements 

o       Conversion  aids/automated  tools 

o       Target  system  software 

Compiler  differences 
Disk  file  management 
New  peripherals 
Utilities 

o       Target  hardware 

Operation 
I/O  procedures 
Data  format 

o       Program  changes  (programming  conventions,  code  and 
I/O  differences) 

o  Data 

Collating  sequence 

Logical  compare  differences 

o       Program  job  control  language 

o  Instructors 

o       Training  facilities 


Training  planning  will  require  coordination  with  contractors. 
The  hardware  vendor  should  be  made  responsible  for  training  personnel  on 
use  of  the  new  equipment  (operations,  procedures,  software)  and 
describing  differences  between  source  and  target  equipment.  Instruction 
on  use  of  automated  tools  may  require  training  by  the  supplying  vendor  or, 
if  developed  internally,  by  in-house  personneL 
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4.8 


PLANNING  THE  SOFTWARE  CONVERSION  SCHEDULE  AND 
DEVELOPING  PLANNING  TRACKING  MECHANISMS 


A  schedule  of  system  and  program  conversions  must  be 
established.  An  inventory  of  all  applications  and  programs  was  made 
during  the  project  initiation  and  conversion  requirements  phases.  This 
established  the  number  of  programs,  files,  and  number  of  lines  of  code  by 
language  and  the  level  of  conversion  effort  (in  terms  of  man-hours)  each 
program  or  system  will  require.  Using  this  inventory,  the  project  planning 
team  should  establish  the  schedule  for  converting  these  programs, 
whether  done  in-house  or  by  an  outside  contractor. 

4.8.1  SOFTWARE  CONVERSION  PRIORITY 

The  first  step  in  scheduling  is  to  determine  the  order  of  the 
files  and  programs  to  be  converted  and  results  expected  in  a  chronological 
list. 

Top  management  or  functional  users  may  require  some 
systems  to  be  converted  earlier  than  others  because  of  future  agency 
plans.  Users  may  also  request  that  their  systems  be  transported  to  target 
hardware  as  soon  as  possible  to  take  advantage  of  its  capabilities.  Based 
on  these  parameters,  plans  must  be  developed  around  resource 
availability. 

4.8.2  RESOURCE  PLANNING  AND  RESPONSIBILITIES 

Plans  must  permit  conversion  to  coincide  with  the  availability 
of  resources,  including  personnel,  equipment,  funding,  and  processing 
time.  This  precludes  inefficient  situations  from  developing  which 
contribute  to  slippage  and  cost  overruns,  such  as: 

o       Hardware  available  but  files  and  programs  not  being 
^  converted, 

o       Files  and  programs  in  a  state  of  conversion  but  no  or 
insufficient  processing  resources. 

This  will  prevent  potential  future  problems  in  terms  of 
overlappir^  responsibilities  and  provide  accountability  for  the  various 
systems,  programs  and  files  earmarked  for  conversion. 

4.8.3  SCHEDULE  PLANNING 

A  detailed  schedule  of  applications,  programs,  and  files  to  be 
converted  should  be  established  regardless  of  whether  conversion  is 
performed  in-house  or  by  an  outside  contractor.  A  number  of  methods 
can  6e»used  to  do  this,  but  they  all  have  common  features. 
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o       Identify  personnel  responsible  for  application  program 
file  conversion. 

o       Establish  time  frame  for  conversion. 

o       Establish  deliverables  or  results  (e.g.,  code  translation, 
unit,  system  and  parallel  tests). 

o       Establish  a  progress  reporting  mechanism  and  tracking 
system. 

Four  types  of  schedules  should  be  maintained,  and  tracked. 
These  schedules  serve  as  cross-references  to  each  other  (33).  They  are: 

o       Application  system  conversion  schedule, 
o       Application  program  conversion  schedule, 
o       File  conversion  schedule, 
o       Personnel  schedule. 

Figures  4-4  through  4-7  are  sample  forms  that  may  be  used 
for  scheduling  activities. 

4.8.4  REPORTING  MECHANISMS  -  TRACKING  AND  MONITORING 

To  maintain  control  and  awareness  of  project  status  the 
project  manager  will  want  to  establish  a  mechanism  by  which  project 
status  is  tracked  and  reported  laterally  and  upward.  At  the  project  team 
level  reporting  is  most  detailed  and  should  contain: 

o       Program/application/file  name, 

o       Individual's  name  responsible  for  conversion, 

o       Start  date/completion  date, 

o       Current  status, 

o       Expected  completion  date, 

o  Problems. 

The  detailed  information  at  the  project  team  level  will  be 
supplied  by  the  task  leaders  for  each  activity  for  which  they  are 
responsible.  For  higher  level  reporting  the  project  manager  will 
summarize  project  status  information  and  disseminate  to  top  management 
in  regular  reports. 

As  shown  in  Figure  4-8  a  number  of  tracking  mechanisms  are 
available,  both  automated  and  manual  Selection  of  a  method  should  be 
based  on  requirements  and  policies  of  the  particular  organization,  and  by 
the  project  manager's  management  style.  The  important  point  here  is  to 
establish  this  mechanism  and  integrate  it  into  software  conversion 
planning. 
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TRACKING/PERFORMANCE  MEASUREMENT 

MODIFICATION  OF  PLANS 

TREND  ANALYSIS 
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Figure  4-8 
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The  tracking  mechanism  should  also  provide  cost  performance 
information  for  each  activity  such  as  estimated  budget,  actual  expenses 
to-date,  and  variance  between  estimated  and  actual  costs.  Variance 
criteria  could  be  established  that  would  flag  potential  cost  overrun 
conditions  for  early,  management  attention. 

Figures  4-9  and  4-10  illustrate  sample  tracking  charts  that 
may  be  used  by  project  managers.  Figure  4-9  is  a  periodic  (weekly, 
biweekly,  etc.)  report  indicating  the  status  for  each  program  (application, 
file).  The  chart  is  completed  at  regular  intervals  by  the  project  manager 
for  a  summary  overview  of  the  entire  conversion.  Figure  4-10  is  an 
application  tracking  chart  that  can  be  used  by  task  leaders  and  the  project 
manager  to  keep  track  of  each  program  within  the  application. 

4.8.5  MULTIPLE  SITE  CONVERSION  SCHEDULES 

Management  of  conversions  at  multiple  sites  (e.g.,  in  a 
distributed  processing  environment)  presents  additional  problems.  If 
centralized  control  cannot  be  exerted,  tracking  and  monitoring  progress 
for  a  multiple  site  conversion  will  be  difficult.  In  multiple-site  conversion 
planning  it  is  essential  that  top  executives  assign  responsibility  for 
maintaining  schedules  and  reporting  conversion  progress. 

4.9  SOFTWARE  PREPARATION  PLANNING 

The  condition  of  software  and  data  files,  prior  to  conversion, 
might  be  such  that  they  cannot  be  efficiently  or  effectively  converted. 
Preparation  activities  have  to  be  planned  (27,  39)  includir^  procedures  to: 

o  Update  documentation, 

o  Remove  obsolete  programs  and  code, 

o  Develop  test  data, 

o  Modify  programs,  as  required,  prior  to  conversion. 

During  the  conversion  requirements  phase,  documentation  was 
reviewed  for  completeness  and  accuracy.  Since  poor  documentation 
directly  affects  conversion  effectiveness,  corrective  action  must  be 
planned  and  tracking  mechanisms  should  be  developed  to  ensure 
documentation  requirements  are  met. 

Plans  to  allow  for  the  removal  of  obsolete  programs  and  code 
should  include  notification  of  users  that  their  asistance  is  required  and 
solicited  in  a  positive,  participatory  role  and  obtaining  support  from  top 
management. 

Test  data  development  planning  is  extremely  important.  It 
affects  the  accuracy  and  effectiveness  of  the  converted  programs  and 
considerable  developmental  lead  time  is  often  required.  This  is  discussed 
in  more  detail  during  the  conversion  preparation  phase. 
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Program  modification  activities  should  be  included  in  the 
conversion  plan.  These  activities  are  listed  below. 

o       Language  Translation 

The  experience  of  some  Federal  agencies  indicated  that 
language  translation  should  occur  prior  to  conversion,  if 
possible,  (e.g.,  Assembly  languages  to  COBOL  for  a 
COBOL  to  COBOL  conversion) 

o  Enhancements 

If  new  user  enhancements  and  functional  redesigns  are 
required,  they  should  preferably  be  scheduled  prior  to  or 
after  conversion,  and  not  during  the  actual  conversion. 

o       Removing  Vendor  Extensions. 

All  programs  should  have  been  examined  for  vendor 
specific  extensions  during  the  requireVnents  f^ase. 
These  should  have  been  identified  and  documented. 
Conversion  planning  should  allow  time  for  the  removal  of 
vendor  specific  extensions  and  coding,  if  possible. 
However,  vendor  extensions  may  provide  capabilities 
that  standard  languages  do  not.  It  may  not  be  possible  to 
remove  these  extensions  and  still  provide  the  same 
output.  Redesign  activities  may  be  required. 

o  Optimization 

Programs  should  be  examined  for  efficiency.  If 
optimization  is  warranted,  plans  should  be  developed  to 
streamline  code  prior  to  conversion.  This  reduces  actual 
conversion  time  and  ensures  production  of  efficient 
software. 

4.10  FUNCTIONAL  USER  AND  EXECUTIVE  INVOLVEMENT 

Functional  users  should  be  involved  throughout  this  phase, 
since  their  cooperation  is  essential  for  a  smooth  conversion  effort.  Users 
should  be  included  in  planning  for  schedulir^  and  testing  (47).  The  cost  of 
user  committee  or  work  group  should  be  included  in  the  total  cost  of 
conversion,  and  the  size  and  involvement  of  this  group  should  be 
determined  partially  on  cost  considerations. 

It  is  unlikely  that  agency  executives  will  wish  to  be  involved  in 
the  conversion  planning  detaiK    However,  the  project  manager  should 
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ensure  that  agency  executives  are  continually  apprised  of  planning 
progress.  This  level  of  management  can  lend  significant  support  and 
assistance  in  resolving  many  planning  conflicts  that  will  occur  outside  the 
authority  of  the  project  manager  or  ADP  manager. 

4.11  HARDWARE  ACTIVITIES 

The  project  team  must  stay  abreast  of  all  activities  relating  to 
the  hardware  procurement,  since  these  activities  will  affect  the 
conversion  plans. 

The  hardware  procurement  decisions  will  impact  planning  and 
conversion  costs  according  to  the  selection  of  the  target  environment 
equipment,  and  the  availability  of  the  target  equipment  for  installation, 
testing,  and  operations. 

It  is  recommended  that  agency  staff  involved  in  hardware 
acquisition  regularly  participate  in  software  conversion  planning 
conferences. 

The  project  manager  must  plan  for  production  and  conversion 
processing.  A  number  of  options  are  available  for  conversion  and  should 
have  been  identified  on  an  operational  and  cost-effectiveness  standpoint 
during  the  requirements  phase: 

o       On  target  hardware  colocated  with  source  hardware, 

o       On  target  hardware  located  in  another  facility, 

o       Through  time  sharing  on  hardware  provided  by  the  target 
vendor, 

o       A  combination  of  the  above  alternatives. 

If  the  target  hardware  is  not  installed  prior  to  the  start  of  the 
conversion,  time  sharing  arrangements  on  a  compatible  machine  will  be 
required.  The  hardware  RFP  may  require  the  vendor  to  provide  these 
services,  or  a  commercial  timesharing  service  may  have  to  be  used. 

The  target  hardware  may  have  to  be  initially  installed  in 
another  location  if  source  hardware  is  still  required  for  production  and  the 
current  computer  facility  is  too  smalL  This  will  require  providing  another 
facility  and  all  appropriate  services,  e.g,  air  conditioning,  power,  raised 
floors. 

The  selection  of  production  and/or  conversion  facilities  is 
dependent  on  a  number  of  variables,  including  cost,  availability,  and  time 
frame.  Preparing  another  computer  room  is  expensive,  requiring  detailed 
planning  and  contract  work.  If  the  target  computer  is  placed  in  another 
facility,  the  conversion  team  may  have  to  relocate. 
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Use  of  a  time  sharing  service  may  result  in  two  additional 

costs: 

o  Equipment  (terminals,  modems)  required  to  interface 
with  the  service, 

o       Computer  time. 

4.12  PLANNING  FOR  LOCATING  THE  CONVERSION  TEAM 

Plans  must  be  prepared  for  providing  facilities  to  house  the 
conversion  team.  Sufficient  space  may  be  available  to  house  the  planning 
team  as  a  group,  but  not  be  large  enough  to  accommodate  the  conversion 
team.  If  members  of  the  team  are  located  in  a  number  of  different 
places,  it  will  be  advantageous  to  move  them  to  one  location  during  the 
conversion  effort  to  increase  management  control.  If  converted  programs 
are  to  be  run  on  hardware  located  external  to  current  facilities,  it  may  be 
advantageous  to  temporarily  relocate  the  conversion  team  to  or  near  that 
facility. 

4.13  PLANNING     FOR    DOCUMENTATION     OF  CONVERTED 
PROGRAMS 

Plans  should  specifically  require  the  conversion  team  to 
produce  documentation  in  accordance  with  FIPS  standards  or  guidelines. 
Additionally,  plans  should  provide  sufficient  resources  and  time  for 
documentation  production.  If  contractors  are  to  be  used  for  software 
conversion,  RFP  planning  should  be  reviewed  to  ensure  documentation 
requirements  are  addressed.  Documentation  improves  software 
maintenance  on  a  day-to-day  basis  and  significantly  aids  programmers  and 
analysts  in  software  conversion. 

4.14  CONTINGENCY  PLANNING 

To  reduce  the  likelihood  of  problems  occuring  during 
conversion,  continuous  review  of  plans  for  potential  problems  can  assist  in 
early  identification  and  resolution  of  many  otherwise  disruptive  influences 
before  they  occur.  No  conversion  will  be  problem-free,  however.  The 
project  manager  should  expect  problems  and  develop  a  plan  to  handle 
those  contingencies  as  they  occur. 

During  conversion  most  unanticipated  problems  occur  due  to: 

o  Failure  to  Maintain  Conversion  Schedules  Schedule 
slippage  can  be  significantly  reduced  if  plans  provide 
adequate  resources  in  terms  of  personnel  and  time  to 
accomplish  conversion  activities.  Problems  are  further 
reduced  if  specific  staff  capabilities  and  limitations  are 
considered  in  developing  schedules  and  assignments. 
However,  the  project  manager  must  anticipate  that  some 
personnel  wiU  fall  behind  schedule. 
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o  Personnel  Changes  Unexpected  losses  of  personnel  will 
occur  due  to  sickness,  extended  vacations,  transfers  and 
termination. 

o  Scheduling  Deficiencies  Because  requirements  can  never 
be  perfectly  defined,  some  schedules  will  be  developed 
that  are  too  rigid  or  unrealistic. 

o  Contractor-Related  Problems  Contractors  frequently 
fall  behind  schedule  or  converted  programs  may  require 
more  optimization  than  anticipated. 

o  Hardware  Delivery  and  Installation  Delays  Hardware 
installation  may  be  delayed  due  to  contractual 
difficulties,  transportation  delays  due  to  strikes, 
manufacturing  difficulties  or  problems  in  site 
preparation. 

Plans  should  provide  a  "reserve"  of  personnel  resources  and 
time  to  permit  the  project  manager  the  flexibility  to  adjust  schedules  and 
levels  of  effort  to  meet  contingencies  on  a  case-by-case  basis  and  still 
accomplish  conversion  by  the  established  end  date.  Task  order  contracts 
can  also  be  negotiated  prior  to  conversion  to  apply  contractors  on  a  quick 
reaction  basis  in  resolving  conversion  problems. 

The  use  of  a  detailed  costing  structure  as  described  in 
Appendix  C  can  assist  the  project  manager  in  contir^ency  planning  and 
execution.  Potential  and  actual  problems  can  be  analyzed  and 
alternatives  selected  at  the  lowest  overall  cost  to  the  agency. 

If  contractors  are  going  to  be  used  to  convert  software  the 
potential  for  problems  can  be  reduced  by  detailed  planning  of  the  RFP  in 
terms  of  expected  deliverables,  documentation,  and  software 
performance.  Penalties  or  awards  in  the  contract  are  recommended  to 
provide  incentive  for  the  contractor  to  stay  on  schedule  and  perform 
effectively. 

4.15  SECURITY/PLANNING 

Security  plans  should  be  developed  to  meet  requirements 
developed  during  the  requirements  phase.  Specific  areas  which  require 
planning  attention  include: 

o  Identification  of  security  software  features  which  meet 
the  needs  of  the  risk  analysis  and  assignment  of 
conversion  team  responsibilities  for  inserting  security 
features  into  software  and  procedures  during  conversion, 
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o 
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o 
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NBS  FIPS  PUBS  31,  41,  48,  65,  and  73  address  security  and  risk 
management  considerations  which  may  be  helpful  in  dealing  with  security 
needs  during  the  planning  stage.  These  FIPS  PUBS  are  described  in 
Appendix  B. 

4.16  TELECOMMUNICATIONS  PLANNING 

^ 

Plans  and  schedules  must  be  developed  to  assure  that  the 
converted  software  and  data  files  can  interface  with  or  be  supported  by 
teleprocessing  hardware  and  software  environment. 

4.17  FORMAL  CONVERSION  PLAN 

All  the  activities  described  in  this  section  should  be 
incorporated  into  a  formal  conversion  plan  which  will  serve  as  the  guide 
during  the  conversion  process.  Figure  4-11  is  a  candidate  outline  of  a 
conversion  plan  that  can  be  used  as  a  guide  by  project  managers. 

The  conversion  plan  should  answer  the  questions  of: 

o  Who  shall  participate  and  conduct  the  conversion? 

o  When  will  the  conversion  take  place? 

o  Where  will  the  conversion  take  place? 

o  How  much  will  the  conversion  effort  cost? 


It  is  recommended  that  the  plan  be  developed  in  draft  form 
and  coordinated  with  the  hardware  acquisition  staff  and  information 
system  users  prior  to  presentation  to  agency  executives  for  approval. 


Access  control  to  sensitive  software,  databases,  system 
libraries  and  documentation. 

Isolating  software  testing  and  the  use  of  non-sensitive 
data  from  the  operational  environment, 

Software  security  assurance  and  certification. 

Conversion  team  security  training. 

Personnel  clearances  to  include  contractors  and 
consultants, 

Operational  procedures  during  testing  and  cut  over. 

Facility  requirements  for  sensitive  software  conversion 
products  (e.g.,  locked  cabinets,  safes  for  sensitive 
listings,  etc.). 

Security  specifications  in  the  RFP  that  must  be 
addressed  by  the  contractor. 

Teleprocessing,  multi-site  and  distributed  processing 
security. 
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Section  Description 

1  Background 

2  Summary  of  Workload  Analysis 

3  Budget  Summary 

4  Personnel  Resources 

-  Management  Team 

-  S/W  Conversion  Team 

-  Availability 

5  Conversion  Schedule 

-  Responsibilities 

-  Schedule 

6  Project  Reporting  and  Tracking 

7  Conversion  Aides 

8  Software  Contract 

9  Training  Plan 

-  Security  Plan 

-  Telecommunication  Plan 

10  Facilities  Plan 

-  Production 

-  Conversion 

-  Team  Location 

-  Equipment  Resources 

11  Contingency  Plans 
Appendices  Budget  Schedule 

SAMPLE  OUTLINE  OF  CONVERSION  PLAN 
Figure  4-11 
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4.18  PLANNING  DECISIONS 


At  the  conclusion  of  the  planning  phase  the  conversion  plan 
will  be  presented  to  agency  executives  for  approval  to  proceed  with 
preparation  and  conversion  activities.  It  is  recommended  that  the  plans 
be  presented  as  part  of  a  formal  briefing  where  the  entire  plan  can  be 
explained  and  an  appreciation  gained  by  top  management  for  planning 
ramifications  and  impacts  on  overall  agency  operations. 

Once  plan  approvals  are  gained  other  management  decisions 
will  involve  approving  conversion  preparation  and  conversion  budgets  and 
implementation  procedures  associated  with  conversion  preparation,  the 
next  phase. 

4.19  ECONOMIC  CONSIDERATIONS 

During  the  conversion  planning  phase,  personnel  costs  should 
continue  to  be  the  major  element  of  cost.  Outside  consultant  services 
may  also  contribute  to  the  cost  of  this  phase  if  these  services  are  used  to 
assist  in  the  planning  effort  in  areas  such  as  developing  the  conversion 
plan,  reviewing  the  conversion  plan  or  actually  preparing  the  formal 
conversion  plan  for  submission  to  upper  management.  Expenses  may  also 
be  incurred  in  the  acquisition  of  automated  project  planning,  tracking  and 
reporting  aids. 

In  this  phase,  the  cost  estimates  developed  for  the  software 
conversion  cost  structure  will  be  refined  as  conversion  activities  are 
defined  in  more  detail.  Cost  information  should  be  developed  at  the  most 
detailed  level  that  is  anticipated  to  be  required.  The  accuracy  of 
individual  cost  estimates  at  this  level  may  not  be  great;  however,  the 
overall  accuracy  of  the  total  cost  of  conversion  should  improve  due  to  the 
use  of  more  detail  and  the  ability  to  estimate  future  project  costs  using 
the  actual  costs  incurred  during  the  previous  phases. 

Conversion  cost  information  will  be  used  during  this  phase  to 
assist  project  management  in  developing  the  conversion  schedule  and 
resource  assignments.  Scheduling  decisions  should  be  based  on  total  cost 
considerations  that  include  the  entire  procurement  action,  not  just  the 
software  conversion  effort.  The  detailed  costing  methodology  given  in 
Appendix  C  can  assist  in  the  assignment  of  resources  to  the  conversion 
effort  by  allowing  a  cost-benefit  analysis  regarding  the  use  of  outside 
personnel  resources  for  conversion  functions.  Also,  the  conversion  cost 
information  will  assist  the  preparation  of  the  formal  conversion  plan  by 
providing  detailed  cost  information  for  budget  planning  by  developing 
budget  schedules  by  function,  phase  or  year;  developing  alternative  cost 
justifications  for  the  use  of  outside  contractors  and  conversion  aids; 
providing  continued  justification  for  the  conversion  effort;  and  ensuring 
the  cost-effectiveness  of  contingency  plans. 
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4.20  PLANNING  MANAGEWffiNT  CHECKLIST 

0       Planning  team  assembled 

o       On-going  costs  being  tracked 

o       Team  augmentees  identified 

System  programmers 

Security 

FCSC 

Consultants 

Telecommunications 

Others 

o       Coordination   and   interface   on-going   with  hardware 
acquisition  staff 

o       Budget  available  to  support  planning 

o       Project  planning  constraints  identified 

Budget  constraints  affecting  conversion 
Hardware  procurement 
Time  and  schedule  limitations 
Others 

o       Conversion  staffing  plan  developed 
In-house  staff 

External  conversion  resources 
o       Training  plan  developed 

o       Plan  for  use  of  contractual  assistance  and  conversion 
tools  during  conversion  completed 

RFP  planning 

Tool  acquisition,  training  and  use  planning 
Contract  monitoring 

o       Software  conversion  schedule  planned 

Priorities  considered 
Conversion  responsibilities  assigned 
Schedule  developed 
Information  system  user  input 
Multiple  site  schedules  considered 

o       Conversion  plan  tracking  mechanism  developed 
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Software  preparation  plan  developed 

Documentation  updates 

Removal  of  obsolete  programs  and  codes 

Test  data 

Preconversion  program  preparation 
Optimization 

Continuous  interface  with  agency  executives  and 
information  users 

Conversion  facilities  planned 

Locating  conversion  team  planned 

Documentation  production  planned 

Contingency  planning  accomplished 

Security  plans  developed 

Telecommunications  and  distributed  processing  plans 
accomplished 

Conversion  plan  drafts 

Internal  agency  coordinationor 
Agency  executive  approval 
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SECTION  5 


CONVERSION  PREPARATION  PHASE 


This  phase  is  a  direct  continuation  of  conversion  planning  in 
that  many  of  the  plans  made  during  that  phase  are  acted  upon.  At  the  end 
of  this  phase,  the  project  manager  will  have  accomplished  all  activities 
that  are  required  to  begin  actual  conversion  (23). 

On  a  timeline  of  conversion  activities,  the  preparation  phase 
may  be  significantly  overlapped  by  conversion  planning  on  one  side,  and 
the  conversion  phase  on  the  other.  This  is  illustrated  in  Figure  5-1. 
However,  the  activities  or  functions  that  occur  during  preparation  are 
distinct  from  planning  or  actual  conversion  activities.  Thus,  preparation 
is  discussed  as  a  separate  phase. 

While  preparing  for  the  conversion,  the  project  manager  must 
continue  to  monitor  project  cost  performance  relative  to  the  initial 
budget  established  during  project  initiation.  The  preparation  activities 
may  require  significant  expenditures  over  a  short  time  period  as  the 
conversion  staff  is  acquired,  facilities  and  equipment  obtained  and 
conversion  tools  developed.  Due  to  the  change  in  magnitude  of  conversion 
related  expenditures,  the  project  manager  may  find  it  necessary  to  track 
project  costs  closely  and  report  regularly  (e.g.,  monthly)  to  top  executives 
to  assure  them  that  cost  controls  are  being  used.  By  comparing  software 
conversion  preparation  costs  estimates  against  actual  costs  incurred,  the 
project  manager  will  be  able  to  refine  cost  estimation  data  and 
procedures.  This  will  permit  more  accurate  projection  of  conversion  costs 
in  future  phases  and  future  conversions. 

During  this  phase  the  project  manager  will  begin  to  see  areas 
in  the  conversion  plan  that  need  improvement  or  revision.  The  conversion 
plan,  however,  should  have  the  flexibility  to  allow  for  changes,  and 
modifications  by  the  project  manager  when  needed. 

5.1  OBJECTIVE 

The  objective  of  this  phase  is  to  complete  all  activities 
necessary  for  the  project  team  to  commence  conversion.  This  objective  is 
accomplished  by  following  the  conversion  plan  and  conducting  all 
activities  that,  if  not  accomplished,  would  interfere  with  or  impede  the 
conversion  effort.  These  include  assembling  the  staff,  training,  obtaining 
software  tools,  obtaining  contractual  assistance,  and  obtaining  facilities 
and  necessary  equipment. 
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5.2 


DECBIONS  IMPACTING  SOFTWARE  CONVERSION 


The  project  manager  must  be  aware  of,  and  prepared  for, 
decisions  made  by  top  management  and  external  organizations.  New 
decisions  may  be  made  that  affect  the  conversion  effort.  The  conversion 
plan  and  schedule  will  have  to  be  modified  based  on  these  new  decisions. 
For  example,  the  budget  may  be  changed,  forcing  the  project  manager  to 
change  conversion  schedules.  The  target  machine  may  be  changed, 
forcing  a  change  in  scheduling,  staffing,  and  training. 

By  continually  addressing  the  full  cost  of  the  conversion 
effort,  the  project  manager  will  be  in  a  position  to  correctly  relate  the 
conversion  cost  impact  of  these  external  decisions  to  agency  executives 
and  involve  this  level  of  management  in  the  total  conversion  effort. 

5.3  CONVERSION  PREPARATION  ACnVmES 

Figure  5-2  illustrates  the  major  activities  that  occur  during 
the  preparation  phase.  They  provide  the  framework  for  the  subsequent 
portions  of  this  section,  and  include  the  following: 

o       The  conversion  budget  must  be  approved, 

o       Work  packages  must  be  developed, 

o       The  project  team  must  be  assembled  and  assignments 
disseminated, 

o       The  training  staff  must  be  assembled  and  training  must 
start, 

o       Contractual  support,  if  needed,  must  be  obtained, 

o       Software  tools  must  be  obtained  or  developed,  and  team 
members  trained  in  their  use, 

o       Equipment    must    be    obtained    and    located  with 
appropriate  users  (e.g.,  terminals), 

o       The  project  team  should  be  located  in  the  facilities  to  be 
used  during  conversion  effort, 

o  Test  data  and  files  must  be  developed, 

o  Program  modifications  should  be  started, 

o  Documentation  should  be  updated, 

o  Hardware  procurement  should  be  monitored. 
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CONVERSION  BUDGET  APPROVAL 

WORK  PACKAGE  DEVELOPED 

PROJECT  TEAM  ASSEMBLED 

TRAINING  INITIATED 

CONVERSION  SUPPORT  ACQUIRED 

EQUIPMENT  OBTAINED 

TEAM  LOCATED  IN  FACILITY 

TEST  DATA  DEVELOPED 

PROGRAMS  MODIFIED 

DOCUMENTATION  UPDATED 

HARDWARE  PROCUREMENT 

MONITORED 

USER  &  MANAGEMENT  INTERFACE 

PROGRESS  TRACKED 

PROBLEMS  RESOLVED 

CONVERSION  DECISION 


MANAGEMENT  DECISION 


CONVERSION  PREPARATION  ACTIVITIES 
Figure  5-2 
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o       Users'  and  agency  executive's  conversion  responsibilities 
must  be  coordinated, 

o       Progress  must  be  tracked  throughout  the  phase, 

o       Problems  as  they  arise  must  be  addressed  and  the 
conversion  plan  modified  as  needed. 

5.4  BUDGET  APPROVAL 

It  is  imperative  that  prior  to  beginning  costly  preparation 
activities,  project  management  obtain  final  approval  for  the  budget.  This 
final  approval  should  reflect  any  recent  budgetary  changes  and  financial 
reporting  requirements  desired  by  management.  In  previous  conversion 
phases,  costs  were  primarily  related  to  personnel  Costs  will  climb  during 
the  preparation  phase  as  the  larger  conversion  team  is  being  assembled, 
contracts  are  awarded,  and  equipment  and  facilities  obtained. 

5.5  DEVELOPMENT  OF  WORK  PACKAGES 

The  project  manager  and  team  leaders  will  develop  and 
assemble  comprehensive  conversion  work  packages  to  facilitate 
conversion  (45). 

Work  package  preparation  includes  the  effort  to  physically 
assemble  all  work  packages  and  to  establish  an  inventory  and  control 
system  for  the  work  packages.  Each  work  package  should  contain  enough 
information  to  enable  the  converter  to  adequately  define  what  is  to  be 
converted  (programs,  files,  control  stream  language,  etc.),  to  ascertain 
the  system/subsystem  functions,  to  identify  all  system/program 
documentation  needing  to  be  redocumented,  and  to  execute  and  test  the 
converted  system/subsystem  to  guarantee  conversion  was  successful.  A 
work  package  should  be  large  enough  to  encompass  a  functional  area  (a 
system  or  subsystem)  and  should  be  made  up  of  information  describing  the 
overall  package  (system/subsystem)  and  its  individual  components 
(programs,  files,  etc.).  The  content  and  makeup  of  individual  work 
packages  should  be  determined  for  each  conversion,  but  will  typically 
consist  of  such  items  as: 


o 

Work  package  transmittal  sheets. 

o 

System/subsystem  descriptions, 

0 

System/subsystem  test  data  and  descriptions. 

0 

System/subsystem  control  stream  language  job  streams, 

0 

System/subsystem  run  documentation, 

0 

Program  inventory  forms. 

0 

File  inventory  forms. 

o 

Program  descriptions, 

0 

Source  and  compile  listings. 

0 

File  descriptions, 

0 

Program  test  data. 

o 

Program  documentation. 

o 

File  documentation. 
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5.6 


ASSEMBLE  CONVERSION  TEAM 


Conversion  team  members  who  will  work  on  the  conversion 
must  be  assembled  or  notified  during  this  phase  (47).  Each  person  must  be 
informed  of: 

o       When  their  conversion  work  will  begin, 

o       To  whom  they  will  report, 

o       Other  members  of  the  project  team, 

o       Reporting  mechanisms  to  be  followed, 

o       Areas  of  responsibility, 

o       Schedule  for  completion  of  tasks, 

o       Priority  ranking  of  assignments, 

o       Training  schedule, 

o       New  work  locations,  if  applicable, 

o       Equipment  available. 

Project  managers  may  find  it  helpful  to  notify  the  conversion 
staff  members  and  inform  them  of  their  responsibilities  using  a  form  or 
written  format.  This  will  improve  understanding  and  ensure  all  pertinent 
information  is  conveyed  to  team  members.  An  initial  group  meeting  is 
recommended  to  discuss  the  overall  goals  and  objectives  of  the  conversion 
effort.  Thereafter  task  leaders  can  then  meet  with  their  respective  staffs 
and  disseminate  detailed  information  to  each  individuaL  Project  team 
members  should  be  made  aware  of  the  fact  that  they  will  be  dedicated  to 
the  conversion  until  their  particular  duties  are  completed. 

Task  leaders  should  hold  regular  meetings  with  their  staff  to 
discuss  progress  and  review  any  problems  which  may  arise. 

Project  team  members  will  be  furnished  work  packages  as  part 
of  tasking.  Project  team  members  should  review  their  particular  tasks, 
and  notify  their  task  leaders  if  they  foresee  any  problems  (e.g.,  not 
enough  time  scheduled  for  a  particular  program  conversion).  The 
problems  that  surface  may  require  modification  of  the  conversion  plan. 

5,7  TRAINING 

The  project  team  members  should  be  scheduled  for  any 
training  that  is  required.  If  on-the-job  training  is  to  be  used  in  lieu  of 
formal  training  courses,  some  initial  productivity  loss  can  be  expected  as 
the  learning  curve  is  gained.  If  on-the-job  trainir^  was  not  considered 
during  the  requirements  phase,  the  conversion  plan  and  schedules  will 
require  adjustment.  In  addition  to  the  conversion  staff,  training  will  be 
provided  operational  personnel,  functional  system  users,  and  other 
members  of  the  ADP  staff,  not  involved  in  conversion,  but  who  will 
ultimately  perform  software-related  work  on  the  target  system. 

The  project  manager  must  acquire  and  provide  the  instructors 
to  train  the  conversion  staff  and  ensure  that  training  plan  objectives  have 
been   met  (33).      Except    for   very   large   conversions,    one    to  two 
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instructors  should  be  sufficient.  Multiple-site  conversions  may  require 
more  trainers  if  software  conversion  is  decentralized  or  if  a  constricted 
conversion  schedule  requires  concurrent  training  at  two  or  more  locations. 

System  programmers  should  make  special  training 
presentations,  as  required,  to  inform  the  conversion  team  of  systems 
programming  impacts  on  application  software.  Also,  any  security-related 
training  should  be  accomplished. 

5.8  OBTAINING        CONTRACTUAL        ASSISTANCE  AND 

AOTOMATED  CONVERSION  TOOLS 

5.8.1  PREPARATIONS  FOR  OBTAINING  CONTRACTUAL 

ASSISTANCE 

Any  planned  outside  assistance  must  be  obtained  during  this 
phase.  The  project  manager  will  have  to  provide  assistance  in  or 
accomplish: 

o       Preparing  the  software  conversion  RFP, 
o       Releasing  the  RFP, 
o       Evaluating  proposals, 
o      Selecting  a  contractor. 

Plans  for  these  activities  were  made  during  the  conversion 
planning  phase  including  planning  the  specific  content  of  the  RFP. 
However,  contractual  procedures  in  obtaining  software  conversion  support 
can  take  from  four  to  six  months  from,  time  of  issuance  of  the  RFP.  The 
contract  must  be  solicited,  evaluated  and  responded  to  by  vendors, 
negotiated  and  awarded.  The  potential  for  time  delays  is  great.  It  is 
essential  that  contractual  assistance  be  obtained  on  schedule  because 
slippage  in  this  area  may  force  slippage  of  the  whole  conversion  effort. 

The  selection  of  a  contractor  to  assist  in  the  conversion 
process  is  critical  since  the  contractor's  ability  will  affect  the  outcome  of 
the  entire  conversion  effort.  Contractual  evaluation  factors  applied  in 
this  phase  include,  but  are  not  limited  to: 

o       History  of  Company 

Specifically  how  long  has  the  vendor  been  in  business; 
financial  standing;  soundness  of  corporate  management 
practices;  background  of  corporate  management. 

o  Experience 

Types  of  conversions  the  vendor  has  been  involved  in; 
success;  problem  resolution  methods;  familiarity  with 
the  agency  target  hardware  environment. 
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o  Personnel 

The  skill  and  experience  level  of  the  employees;  turn 
over  rate. 

o       Cost,  Deliverables  and  Responsibilities 

The  proposed  deliverables  and  schedule;  responsibilities 
assumed  by  the  contractor;  contract  cost. 

o  Testing 

Ability  of  the  contractor  to  meet  test  objectives; 
proposed  alternatives;  acceptability  of  alternatives. 

After  selecting  a  software  contractor,  meetings  should  be 
held  with  their  representative.  It  is  important  that  lines  of  communica- 
tion be  kept  open  and  that  misunderstandings  be  quickly  detected  and 
resolved.  Since  a  contract  statement  of  work  can  never  completely 
address  all  contingencies  that  occur  during  the  conversion,  it  is  important 
to  develop  and  maintain  a  professional,  cooperative  working  relationship 
with  the  contractor. 

The  contractor  should  thoroughly  understand  how  progress  is 
going  to  be  monitored,  and  how  performance  penalties  or  awards  will  be 
determined.  This  includes  identifying  to  the  contractor  which  staff 
members  responsible  for  specific  areas  of  the  conversion  are  contractual 
points  of  contact. 

5.8.2  AUTOMATED  TOOLS 

Automated  tools,  if  used,  must  be  obtained  or  developed 
during  this  phase.  If  they  are  to  be  obtained  from  a  commercial  source, 
another  RFP  may  have  to  be  released.  (Note  that  the  decision  to  develop 
the  tools  in-house  or  obtain  them  from  an  outside  source  was  made  in 
earlier  phases.)  Potential  contractors  should  be  required  to  perform  a  live 
test  demonstration  on  a  sample  program  prepared  by  the  project  team. 
Results  should  be  evaluated  for  accuracy  and  efficiency  and  based  upon 
the  full  cost  impact  of  each  proposal  on  the  total  software  conversion 
cost.  The  cost  of  the  automated  tools  should  be  compared  to  original 
estimates  and,  if  significantly  greater  than  the  estimates,  their  cost- 
effectiveness  should  be  reevaluated. 

If  the  tool  is  to  be  developed  in-house,  a  staff  must  be 
assigned  to  develop  the  tool  as  well  as  tool  verification  data.  Data 
processing  resources  must  be  made  available  to  the  developers.  After 
tools  have  been  acquired  or  developed,  the  conversion  team  members 
must  be  trained  in  their  use. 
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5.9  LOCATING  CONVERSION  TEAM/OBTAINING  EQUIPMENT 


Project  team  members  ^ould  be  located  in  their  team 
facilities.  New  offices  should  be  equipped  with  adequate  furniture  -desks, 
chairs,  lights,  telephones.  The  project  manager  should  ensure  that 
adequate  resources  are  available  to  those  team  members  who  require 
moving  assistance  (e.g.,  boxes,  transportation  etc.)  (4). 

Relevant  data  processing  equipment  that  project  team 
members  may  require  (e.g.,  card  files,  terminals,  modems,  and  telephones) 
must  also  be  obtained.  These  should  be  in  place  and  tested  prior  to 
starting  the  actual  conversion  process. 

5.10  CONVERSION  FACILITIES 

Management  must  obtain  conversion  facilities,  and  develop 
procedures  for  use.  Information  distributed  to  the  project  team  prior  to 
the  conversion  should  include: 


o 

Location  of  facilities, 

o 

Operational  procedures, 

0 

Hours  available. 

0 

Points  of  contact. 

o 

Access  and  security  issues. 

0 

ADP  communications,  telephone  numbers. 

0 

Logon  procedures. 

0 

Protocols  and  passwords  required  to  log  on  hardware. 

0 

Troubleshooting  procedures. 

5.11  DEVEL0PB4ENT  OF  TEST  FILES  AND  DATA 

Good  test  data  should  be  developed  prior  to  code  conversion. 
If  the  conversion  is  to  be  done  totally  in-house,  project  team  members 
will  have  to  develop  the  test  data.  A  management  question  arises, 
however,  when  a  software  contractor  is  used.  Who  should  develop  the  test 
data,  the  contractor  or  the  organization?  All  of  the  organizations 
interviewed  in  preparation  of  this  guide  developed  their  own  test  data. 
However,  it  may  be  feasible  for  the  contractor  to  develop  the  test  data 
for  agency  review  and  validation.  Deciding  who  should  develop  test  data 
will  have  been  accomplished  during  the  requirements  phase.  Whether  test 
data  is  developed  by  an  agency  or  contractor,  it  is  important  that 
information  systems  users  have  the  opportunity  for  input  and  review. 

Test  data  preparation  and  generation  includes  all  creation, 
preparation,  and  generation  of  test  data  sets  to  validate  the  converted 
programs,  files,  and  systems  (45).    It  should  ensure  that  unit  test  data 
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sets  are  small  enough  in  volume  to  minimize  testing  costs,  but  thorough 
enough  to  exercise  at  least  70%  of  the  logical  paths  of  the  program. 
Several  studies  have  Independently  shown  that  typically  a  system  will 
spend  50%  of  the  run  time  in  4%  of  the  object  code;  and  10%  of  the  code 
typically  will  account  for  90%  of  the  run  time.  The  implication  is  that 
90%  of  the  testing  may  only  be  exercising  10%  of  the  code.  Thus, 
ensuring  that  about  70%  of  the  logic  paths  are  executed  may  still  be 
inadequate.  The  70%  tested  must  include  the  code  that  is  typically  the 
most  frequently  used.  Preparation  of  test  data  for  execution  of  the 
programs  following  clean  compilation  should  stress  the  use  of  data  that 
will  execute  a  maximum  amount  of  the  program  logic  with  a  minimum 
amount  of  input  data.  Because  test  data  are  usually  prepared  and 
generated  on  the  source  computer,  their  preparation  and  generation 
should  include  the  conversion  or  transfer  of  the  test  data  files  to  the 
target  computer  so  file  comparisons  can  be  performed. 

5.12  PROGRAM    MODIFICATION    AND    INCORPORATION  OF 

USER  ENHANCEMENTS  INTO  SOFTWARE 

Any  additional  modification  of  programs  should  occur  during 
this  phase.  Project  team  members  should: 

o  Remove  any  obsolete  programs  and  code.  This  will 
require  team  members  to  interact  with  users. 

o  Program  desired  user  enhancements  into  the  system  in 
advance  of  conversion.  It  would  be  preferable  to  do  this 
after  the  conversion.  However,  if  time  allows  or 
enhancements  are  mandatory,  changes  should  be 
accomplished  during  this  phase. 

o  Remove  vendor  extensions  from  the  code.  However, 
this  may  not  be  possible  because  the  extensions  may 
meet  a  requirement  that  cannot  be  provided  by  standard 
lar^^es,  or  by  target  vendor  extensions.  Project  team 
members  should  familiarize  themselves  with  these 
extensions,  reprogram  where  possible,  and  develop 
alternative  plans  for  extensions  that  cannot  be  removed. 

o  Optimize  software  to  shorten  conversion  time  and  ensure 
efficient  code  is  converted. 

At  some  point  immediately  prior  to  a  system  conversion, 
software  development  should  be  frozen.  This  will  help  ensure  that  outputs 
on  source  and  target  systems  are  the  same  during  parallel  testing. 
However,  the  experience  of  many  conversion  managers  indicates  that  this 
is  more  difficult  in  practice  than  in  theory.  Functional  users  often 
require  modifications  at  some  point  during  the  conversion,  and  some 
systems  cannot  be  frozen.    Established  and  enforced  systems  change 
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procedures  can  reduce  problems  of  simultaneously  converting  software 
that  is  under  development.  Change  control  procedures  permit 
identification  of  a  software  version  configuration  and  a  continuing  record 
of  all  changes  as  they  are  applied  to  specific  versions.  A  version  can  be 
selected  for  conversion  and  the  recorded  changes  added  later.  If  an 
agency  does  not  have  good  change  control  procedures  in  effect,  the 
project  manager  should  enlist  the  support  of  the  ADP  manager  to 
establish  and  implement  change  procedures  prior  to  actual  conversion. 

5.13  DOCUMENTATION 

The  project  manager  will  have  to  ensure  that  documentation  is 
updated.  Documentation  should  be  brought  to  a  current  state  for  all 
software  that  is  not  going  to  be  completely  redeveloped  (33).  For 
software  documentation  that  is  in  a  poor  state  of  maintenance  or  is  non- 
existent, the  project  team  will  have  to  do  considerable  research  and 
writing.  Some  training  may  be  necessary,  particularly  for  newly  assigned 
personnel  or  contractors,  in  agency  documentation  standards  or  FIPS  PUB 
38  and  64.  Managers  will  have  to  arrange  for  administrative  support  in 
documentation  production  and  perform  quality  reviews  as  documentation 
is  produced.  It  is  advisable  to  produce  documentation  on  automated 
equipment  (eg,  word  processing)  to  facilitate  revision  and  maintenance. 

If  user  documentation  revision  or  update  is  required  (i.e  ,  users 
manuals)  managers  will  have  to  coordinate  with  functional  users  and 
achieve  their  cooperation  in  the  documentation  effort. 

5.14  HARDWARE  PROCUREMENT 

The  project  manager  must  keep  informed  of  all  activities 
relating  to  the  hardware  procurement.  The  project  manager  of  one 
agency  interviewed  did  not  stay  abreast  of  hardware  procurement 
activities,  and  was  surprised  when  target  hardware  was  switched  midway 
through  the  conversion  effort.  This  forced  abrupt,  disruptive  changes  in 
planning  and  conversion  preparation. 

5.15  USER  AND  TOP  MANAGEMENT  INVOLVEMENT 

As  in  all  other  phases,  functional  users  should  be  involved 
throughout  conversion  preparation.  Users  have  to  keep  the  project  team 
informed  of  any  new  functional  requirements  that  impact  on  software  to 
be  converted,  particularly  those  that  occur  from  outside  the  agency. 
User's  cooperation  is  also  needed  in  modifying  programs,  freezing  the 
software,  and  in  obtaining  documentation. 
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5.16  TRACKING  PROGRESS 


The  tracking  mechanism,  developed  during  the  conversion 
planning  phase  is  implemented  during  this  phase.  After  assignments  are 
disseminated,  management  must  track  the  progress  made  by  the  project 
team  as  it  prepares  for  conversion. 

At  the  project  management  level  all  preparation  activities 
will  be  tracked  in  detaiL  The  project  manager  must  have  immediate 
access  to  information  on  a  daily  basis  concerning  progress  in: 

o       Program  modification, 

o       Program  preparation, 

o  Documentation, 

o       Test  data  development, 

o       Facilities  -  staff  and  conversion, 

o       Equipment  installation, 

o      Software  conversion  contract, 

o       Automated  tools  development. 

The  project  manner  cannot  develop  the  project  details  alone. 
The  project  team  leaders  will  assist  in  compiling  and  reporting  on  assigned 
project  responsibilities  (e.g.,  specific  program  modifications, 
documentation,  etc.).  Project  status  should  be  displayed  on  visual 
tracking  aids  selected  for  use.  Bar  charts  are  commonly  used  since  they 
can  display  the  status  of  all  project  activities  and  whether  objective  end- 
dates  have  been  reached.  Regularly-scheduled  project  team  meetings  (at 
least  to  the  team  leader  level)  are  recommended,  no  less  than  on  a  weekly 
basis,  to  allow  team  members  to  surface  potential  problems  and  to  keep 
the  entire  team  apprised  of  progress. 

At  levels  above  the  project  manager,  project  status 
information  should  be  summarized  and  regularly  reported  no  less  than  on  a 
monthly  basis.  Graphics  (e.g.,  bar  charts)  displaying  status  of  major 
preparation  activities  are  equally  useful  in  reporting  project  status  to 
agency  executives  as  the  more  detailed  charts  are  to  the  project  manager. 
Scheduled  project  status  briefings  maintained  since  the  project  initiation 
phase  will  continue  and  assist  in  keeping  top  management  informed. 
Exception  reports  of  significant  problems,  beyond  the  capability  of  the 
project  manager  to  resolve,  should  be  immediately  provided. 

5.17  DEALING  WITH  UNFORESEEN  PROBLEMS 

Unanticipated  problems  begin  to  surface  during  this  phase.  As 
problems  are  identified,  they  must  be  addressed.  This  is  a  key 
management  issue.  Postponement  of  problem-solving,  no  matter  how 
minor  the  problems  appear,  may  result  in  having  to  cope  with  larger, 
compounded  problems  durir^  actual  conversion. 
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Common  problems  that  may  arise  during  conversion 
preparation  can  be  associated  with  the  following  list.  Comments  are 
offered  on  how  the  occasion  of  these  issues  may  be  reduced  or  avoided. 


o       Unexpected  management  decisions 

Budget  modifications 
Change  in  target  machine 

Schedule  change  forced  on  project  management 

Comment:  Continuing  coordination  with  agency  staff 
members  and  regular  executive  level  project  status 
briefings  may  provide  advance  information  to  plan 
and  execute  schedule  changes. 


o       Project  team 


-~-      Personnel  losses 

Poor  personnel  morale 

Skills  don't  meet  expectations 

Personnel  cannot  be  dedicated  to  project 

Comment:  Regular  team  briefings  can  improve  morale.  Quick 
reaction  task  order  contracts  can  be  executed  to 
acquire  additional  staff  and  skills  needed. 


o  Training 

Inadequate  training 
Poor  attendance 

Conversion  environment  changes  (target  hardware 
or  software  is  changed) 


Comment:  Training  plans  should  have  provisions  for  remedial 
training  and  additional  classes.  Each  absence 
should  be  challenged.  Training  schedules  published 
well  in  advance  reduce  conflicts  with  leaves,  etc. 


o       Contractual  assistance 


Delays  in  preparing  RFP  package 
No  vendor  bids 

Vendors  cannot  meet  requirements  of  RFP 
Poor  customer/contractor  communications 

Comment:  Accumulate  RFP  input  in  looseleaf  form  as  it  is 
developed  in  the  requirements  phase.  This  eases 
RFP  preparation.  Advertise  well  in  advance  an 
intent  to  issue  an  RFP  and  what  the  scope  of  work 
will  be.  On  large  projects  insist  on  a  full-time 
contractor  project  manager  and  have  the  COTR  on 
the  project  management  team. 
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o       Automated  tools 


No  commercial  tool  available  to  meet  agency 

requirements 

No  vendor  bids 

Delays  in  development  in-house 
Tools  inefficient  and/or  inaccurate 

Comment:  Assessment  of  automated  tool  requirements  early 
in  the  requirements  phase  should  preclude  this 
issue 

o       Project  team  facilities 

Delays    in    obtaining    equipment,    e.g.,  office 
furniture,  telephones,  modems,  terminals,  etc. 
Facilities  are  unavailable 
Delays  in  moving  personnel 

Comment:  Identify  requirements  early;  obtain  budget. 

o       Conversion  facilities 

Low  priority  given  to  project  team  personnel 
Facilities  are  inadequate  or  inconvenient 
Data  communication  problems 
Unreliable  hardware 

Comment:  Maintain  ongoing  coordination  with  hardware  staff. 

Anticipate  problems  early  and  explain 
ramifications  at  executive  level  project  reviews. 
Identify  backup  hardware  and  communications  in 
contingency  planning. 

o       Test  data 

Developed  test  data  is  inadequate 
Delays  in  developing  test  data 

Comment:  Solicit  early  user  input  in  developing  test  data. 

Stress  continuous  agency  maintenance  of  test  data 
packages. 

o       Program  modification 

Users  continue  to  enhance  their  programs,  or  re- 
quest enhancements 

Modification  more  difficult  than  anticipated 
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omment:  Established  change  control  procedures,  good 
documentation,  and  use  of  standard  lar^uages,  and 
restricted  use  of  vendor  unique  utilities  during 
normal  software  operations  should  ease  problems  in 
this  area. 


o  Documentation 


Additional  documentation  not  available 
Users  do  not  cooperate 

Development  or  modification  of  documentation 
more  difficult  than  anticipated 

Comment:  Establish  and  enforce  documentation  standards  at 
all  times. 


o       Hardware  procurement 

Target  hardware  charges 

Delays  in  obtaining  target  hardware 

Comment:  Continued  and  close  coordination  with  hardware 
acquisition  staff  is  a  must. 

o       User  involvement 


Users  do  not  cooperate:   additional  enhancements, 

modifications  requested 

Users  fail  to  provide  documentation 

Users  react  negatively  to  freezing  of  software 

Comment:  Maintain  regular  reporting  to  top  agency  officials 
to  gain  their  support  and  cooperation.  Continue 
user  interface.  Involve  users  in  project  planning. 

o       Tracking  progress 

Project  team  members  fail  to  maintain  records 
Project   team    members   fail   to   use  reporting 
hierarchy 

Tracking  mechanism  does  not  adequately  track 
progress 

Project    management    fails    to    use  tracking 
mechanism  adequately 
Costs  not  tracked 


Comment:  Assign  reporting  responsibilities;  review  plans  and 
tracking  for  flexibility  and  ease  of  use.  Plans 
should  be  "looseleaf"  in  nature.  Rely  on  visual 
tracking  aids. 
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5.18  CONVERSION  PREPARATION  MANAGEMENT  DECISIONS 


At  the  conclusion  of  the  preparation  phase,  agency  executive 
approval  will  be  given  to  proceed  with  conversion  activities.  In  an  actual 
conversion  environment  conversion  will  commence  before  all  preparation 
activities  are  completed.  The  actual  conversion  decision  will  be  based  on 
a  determination  that  conversion  can  commence  with  minimum  disruption 
due  to  uncompleted  preparations 

5.19  ECONOMIC  CONSIDERATIONS 

Preparation  for  conversion  may  require  large,  one-time 
expenditures  to  activate  the  software  conversion  plans.  As  a  result,  cost 
elements  other  than  personnel  may  become  significant.  These  include 
one-time  expenses  for  the  purchase  of  conversion  tools,  ADP  equipment, 
and  office  furniture  and  fixtures  to  accommodate  additional  conversion 
team  resources  (e.g.,  contractors).  Rentir^  these  items  may  reduce  the 
magnitude  of  these  costs;  however,  certain  nonrecurring  expenses  for 
freight,  installation  and  site  preparation  may  still  occur.  Personnel  costs 
and  related  occupancy  costs  will  increase  during  this  phase  as  the  project 
team  is  assembled.  Items  such  as  moving  expenses,  new  hire  expenses, 
and  office  space  renovation  expenses  should  not  be  overlooked. 

The  software  conversion  life  cycle  cost  information  should 
continue  to  be  defined  at  the  same  level  of  detail  used  during  the  previous 
phase.  The  cost  information  should  be  updated  as  actual  expenses  are 
incurred.  Cost  estimates  prepared  for  the  conversion  phase  should  be  to 
reflect  the  actual  expenses  of  the  conversion  team  assembled  during  this 
phase,  and  refined  to  incorporate  any  changes  in  project  scope  or 
schedules. 

The  primary  use  of  the  software  conversion  cost  information 
during  this  phase  is  the  comparison  of  actual  expenses  to  cost  estimates. 
Significant  cost  variations  identified  should  be  reported  to  top  manage- 
ment for  early  resolution  of  potential  budgetary  problems.  Equipment, 
facilities  and  conversion  tool  acquisitions  should  be  evaluated  using  the 
total  project  cost  of  the  conversion  effort  to  determine  the  lowest  cost 
alternative.  During  this  phase  minor  adjustments  in  the  decision  plans 
may  be  made.  These  adjustments  should  also  be  evaluated  on  the  full  cost 
impact  of  each  alternative  to  assure  the  cost-effectiveness  of  any 
changes. 

Communication  with  management  and  users  during  this  phase 
should  include  cost  considerations,  such  as  expenses  to-date,  projected 
budgets,  and  evaluation  of  the  continued  cost-effectiveness  of  the 
proposed  conversion  effort. 
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CONVERSION  PREPARATION  MANAGEMENT  CHECKLIST 

o       Conversion  preparation  budget  adequate  and  approved 
o       Costs  being  tracked 

o       External  impacts  affecting  preparation  and  conversion 
assessed 

Conversion  project  budget  changes 
Target  hardware  changes 
Other 

o       Project  team  reorganized  for  conversion  preparation 

o      Staffing  schedules  prepared 

o      Training  plans  in  effect 

o      Software  conversion  RFP 

Prepared 
Issued 
Negotiated 
Contractor  selected 

Contractor/project  management  coordination 

o       Automated  tools  acquired 

Contractor  developed 
In-house  developed 

o      Staff  trained  in  tool  use 

o       Conversion  project  team 

Notified 
Briefed 

Responsibilities  assigned 
Assembled  and  located 
Trained 

o       Conversion  facilities  obtained 

Computer  support 
Terminals 

Team  informed  of  procedures 
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Test  data  and  files  available  and  tested 

Information  system  user  input 
Software  development  frozen  (if  possible) 
Change  control  procedures  in  effect 
Programs  modified  as  required  prior  to  conversion 
Documentation  completed 

Continuous  and  ongoing  coordination  and  reporting  with 

Top  management 
Information  system  users 
Hardware  staff 

Plan  tracking  in  effect 

Contingency  plans  reviewed  for  effectiveness,  remedial 
action  taken 

Costs  being  tracked 

Cost  estimates  refined  for  future  use 
Extraordinary  costs  reported  to  agency  executives 

Conversion  budget  and  preparations  reviewed 

Agency  decision  to  convert 
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SECTION  6 


THE  CONVERSION  PHASE 


During  the  conversion  phase  the  adequacy  of  planning, 
organization,  and  project  management  is  revealed.  The  conversion  phase 
also  provides  the  opportunity  to  develop  a  software  posture  which  will 
directly  affect  the  success  of  any  future  conversions. 

6.1  OBJECTIVE 

The  objective  of  the  conversion  phase  is  to  complete  the 
conversion  as  effectively  as  possible  in  the  time  provided,  and  within 
authorized  budget  limitations.  While  the  objective  is  simply  stated,  the 
decisions,  organization,  and  activities  that  relate  to  attaining  this 
objective  are  complex  and  wiU  require  continuing  and  involved  project 
man^ement  attention  throughout  the  effort. 

6.2  CONVERSION  PHASE  ACTIVITIES 

Figure  6-1  illustrates  the  major  activities  that  occur  during 
conversion.  These  are: 

o  Team  management,  organization  and  staffing, 

o  External  interface  and  coordination, 

o  Training, 

o  Security  considerations, 

o  Software  conversion, 

o  Unit  and  systems  testing, 

o  Parallel  testing  and  crossover, 

o  Documentation. 


These  activities  will  be  discussed  in  subsequent  portions  of  this  section. 
The  purpose  of  the  discussion  is  not  to  provide  managers  minute,  technical 
details  associated  with  the  various  functions,  e.g.,  software  testing.  Many 
technical  references  exist  to  provide  this  information  if  the  experience  is 
lacking  in  the  project  management  or  project  team  staffs.  Rather,  the 
intention  is  to  provide  managers  an  understanding  of  the  functional 
relationships  and  the  management  considerations  that  apply  to  preclude  or 
reduce  problems  during  conversion  and  achieve  the  goal  of  an  efficient 
and  effective  software  conversion. 
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MANAGING  CONVERSION  TEAM 
COMPOSITION  AND  ASSIGNMENTS 

EXTERNAL  INTERFACE  &  COORDINATION 

TRAINING 

SOFTWARE  CONVERSION 

SYSTEMS  TESTING 

PARALLEL  TESTING  -  UNIT  TESTING 

DOCUMENTATION 

CONVERSION  TERMINATION  DECISION 

T 

MANAGEMENT  DECISION  ▼ 


CONVERSION  PHASE  ACTIVITIES 
Figure  6-1 


SYSTEMS  TESTING  -  UNIT  TESTING 
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6.3 


MANAGEMENT,  ORGANIZATION  AND  STAFFING 


Managing  the  skill  mix  and  composition  of  the  project  team 
will  be  the  biggest  management  challenge  during  the  conversion  phase. 
There  are  multidimensional  variables  of  skills,  numbers  of  personnel,  and 
time  requirements.  See  Figure  6-2. 

6.3.1  TEAM  COMPOSITION 

During  the  software  conversion  phase  the  project  team  will  be 
composed  of  analysts  and  programmers  augmented  or  assisted  by  systems 
programmers,  training  personnel,  system  operators,  security  personnel  and 
information  systems  users.  The  skill  mix  is  usually  made  up  of  in-house 
personnel  as  weU  as  consultants  and  contractors  in  levels  of  effort 
established  during  the  requirements  phase  and  applied  accordir^  to 
conversion  plans  and  schedules. 

Initially  the  project  team  consists  primarily  of  analysts  and 
programmers.  As  unit  testing  is  implemented,  systems  operators  and 
programmers  will  assist. 

Midway  through  the  conversion,  information  systems  users  wiU 
be  assisting  in  system  and  initial  parallel  testing.  Security  personnel  and 
information  systems  users  will  be  assisting  in  software  verification  and 
validating  achievement  of  security  and  privacy  software  requirements. 
Input  from  data  entry  personnel,  tape  and  disk  libraries  and  input/output 
staff  members  wiU  permit  the  project  manager  to  develop  efficient 
procedures  during  parallel  testing  and  refine  user  and  operator  manuals. 

In  the  later  stages  of  the  conversion,  as  applications  on  the 
new  system  complete  parallel  testing  and  are  accepted  by  users,  the  need 
for  analysts  and  programmers  converting  code  diminishes.  Project  team 
activities  are  primarily  associated  with  parallel  testing,  software  security 
certification,  user  acceptance  and  documentation.  As  people  are  no 
longer  required  in  conversion  activities,  they  revert  back  to  normal 
duties. 

6.3.2  PROJECT  TEAM  ASSIGNMENTS 

Assignments  and  schedules  for  the  conversion  project  team 
will  have  been  issued  during  conversion  preparations.  However,  new  staff 
members,  including  contractors,  will  most  likely  be  required  to  replace 
personnel  losses  or  applied  to  resolve  unexpected  problems  as  a  result  of 
contingency  planning.  Providing  these  new  additions  written  instructions 
on  their  project  duties,  responsibilities  and  reporting  procedures  will 
facilitate  their  integration  into  the  project  effort. 
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6^.3 


PROJECT  TEAM  INTERNAL  INTERFACE 


During  conversion,  project  meetings  are  particularly  important 
to  keep  the  entire  team  appraised  of  status.  On  large  conversions  the 
total  staff  involvement  at  any  one  time  can  be  30-40  personnel  Team 
meetings  of  this  size  are  impractical  on  a  day-to-day  basis.  Periodically 
(e.g.,  on  a  weekly  basis)  the  team  should  be  apprised  of  progress  or  status. 
The  project  manager  should  hold  more  frequent  meetings,  probably  daily, 
with  task  leaders  to  coordinate  conversion  activities. 

The  press  of  conversion  activities  will  create  tendencies  to 
cancel  or  postpone  meetings  with  the  team  or  task  leaders.  This  should  be 
avoided.  Besides  keeping  the  project  staff  informed  of  status,  meetings 
assist  in  developing  a  team  spirit  and  sense  of  belonging  to  an 
organization  in  an  otherwise  ad  hoc  assembled  group  of  personnel.  Most 
importantly,  since  management  commonly  assigns  hi^h  quality  talent  to 
conversion  team  duties,  meetings  can  focus  considerable  talent  and 
experience  on  means  to  resolve  problems  that  may  arise. 

Conversion  team  leaders  and  designated  specialists  working  on 
specific  conversion  tasks  should  be  inputting  status  to  tracking 
mechanisms  established  for  project  controL  There  will  be  a  tendency  for 
members  to  delay  this  input  due  to  the  press  of  business.  Project 
managers  wiU  have  recurring  needs  for  status  information  quickly  in  order 
to  respond  to  top  management  requests  or  to  respond  to  inquiries 
originating  outside  the  agency  (e.g.,  GSA).  Project  managers  should 
therefore  monitor  the  degree  of  currency  of  project  status  information 
and  discipline  or  revise  the  tracking  procedures  if  information  currency 
slips. 

Graphics,  such  as  bar  charts,  should  be  used  at  the  team  level 
since  they  visually  aid  the  project  mane^er  and  the  team  in  deter minir^ 
status.  Conversion  task  leaders  and  other  specialists  (e.g.,  security)  also 
will  be  inputting  status  and  historical  information  into  a  history  log.  This 
log  should  be  in  looseleaf  form  but  organized  in  some  fashion  which  wiU 
support  the  post  conversion  analyses.  The  format  described  in  Section  7 
for  the  analysis  report  is  suggested.  In  addition  to  its  historical 
significance,  this  log  will  be  useful  to  newly-assigned  team  members  in 
gaining  an  overview  and  understanding  of  project  objectives  and  status. 

6.4  EXTERNAL  INTERFACE  AND  COORDINATION 

During  conversion  regular  and  continuous  interface  is  required 
with  agency  executives,  functional  information  systems  users,  hardware 
operations  personnel  and  any  contractors  employed  for  software 
conversion. 
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6.4.1 


AGENCY  EXECUTIVES 


Regular  project  briefings  and  other  status  reporting 
mechanisms,  established  and  ongoing  from  project  initiation,  are  critical 
during  the  conversion  phase.  Although  contingency  and  other  planning 
should  have  precluded  many  problems  arising  during  the  conversion  phase, 
no  conversion  will  be  100%  devoid  of  problems.  Significant,  unforeseen 
problems  ^ould  be  expected  due  to  influences  outside  the  control  of  the 
agency,  ADP  or  project  manager.  Prime  examples  which  have  affected 
Federal  conversions  include  budget  cuts  and  hiring  freezes.  If 
contingency  planning  has  not  provided  the  project  manager  the  flexibility 
to  deal  with  these  problems,  support  of  top  management  will  be  required. 

6.4.2  INFORMATION  SYSTEMS  USERS 

Close  and  continuous  interface  will  be  required  with  functional 
information  system  users  during  conversion.  Their  support  to  conversion 
efforts  is  critical  during  this  phase. 

Information  systems  users  will  assist  the  project  team  in 
system  and  parallel  testing.  Additionally,  if  security  or  privacy  features 
have  been  engineered  into  software,  users  will  have  to  assist  in  security 
verification  and  software  accreditation  procedures.  Project  managers  can 
expect  that  busy  users  will  experience  some  inconvenience  as  a  result  of 
conversion  activities.  Their  continuing  support  will  be  directly  related  to 
rapport  established  prior  to  actual  conversion. 

User  interface  is  most  important  in  freezir^  new  software 
developments  during  conversion.  Frozen  software  reduces  many  problems 
for  the  project  manner.  User  and  top  managment  support  in  freezir^ 
development  will  have  been  achieved  during  prior  conversion  phases. 
However,  since  the  time  of  actual  conversion  can  be  quite  ler^thy, 
extending  over  a  year  in  large  conversions,  project  managers  can  expect 
impatience  and  some  support  to  wane  for  postponing  new  enhancements. 
Attention  to  developing  conversion  priorities  and  schedules,  approved  by 
users  during  the  planning  phase  and  adherence  to  these  schedules  during 
conversion  will  build  confidence  among  users  that  their  inconvenience  in 
obtaining  new  enhancements  will  be  minimaL  If  new  enhancements 
cannot  be  avoided,  change  control  procedures  can  reduce  the  trauma  of 
converting  dynamic  systems  and  programs. 

6.4.3  HARDWARE  AND  OPERATIONS  STAFF  INTERFACE 

Considerable  support  will  be  required  from  the  operations 
staff  particularly  during  testing.  Although  testing  can  be  planned  and 
scheduled,  actual  testing  will  require  many  schedule  modifications  as 
software  systems  are  debugged.  These  schedule  changes  will 
inconvenience  the  operations  staff.  Project  managers  should  encourage 
participation  of  operations  staff  members  at  project  meetings  to  promote 
operations  staff  cooperation  and  encourage  their  input  on  day  to  day 
scheduling  adjustments. 
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6.4.4 


CONTRACTOR  INTERFACE 


Planning  for  conversion  with  large  contractor  software 
conversion  efforts  ^ould  have  provided  a  COTR  on  the  project  managers 
staff  and  a  contractor  project  officer.  If  this  has  been  accomplished,  the 
day  to  day  interface  necessary  to  keep  contractual  efforts  on  track  with 
in-house  conversion  actions  will  be  facilitated. 

6.5  TRAINING 

Most  of  the  training  for  conversion  was  accomplished  in  the 
previous  phase,  conversion  preparation.  Nevertheless  some  training  will 
be  required  in  the  conversion  phase. 

If  newly  assigned  personnel  are  applied  to  the  conversion  team 
to  replace  unexpected  losses,  they  will  have  to  be  trained  in  their  duties. 
Additionally,  there  will  be  ongoing,  ad  hoc  training  requirements  to 
operators,  data  librarians  and  data  entry  personnel  as  operating 
procedures  are  refined  during  testing.  This  training  is  normally 
accomplished  by  members  of  the  project  team.  Project  managers  should 
ensure  that  the  necessary  procedures  and  documentation  (e.g.,  operations 
manuals)  are  developed  and  used  in  conjunction  with  this  training- 
Information  systems  users  normally  do  not  require  extensive 
training  unless  new  functional  changes  are  included  in  the  converted 
software.  Some  user  training  may  be  required  when  users  assist  in 
systems  testing.  During  parallel  testing  users  will  have  to  be  trained  to 
the  extent  that  they  can  differentiate  between  and  compare  the  source 
and  target  hardware  production  runs. 

6.6  SECURITY  CONSIDERATIONS 

The  project  manager,  working  in  conjunction  with  the  agency 
information  system  security  official  and  the  information  systems  users 
will  ensure  that  the  design  reviews  are  conducted  during  systems  testing 
and  that  sensitive  systems  are  carefully  monitored  for  security  during 
parallel  testing.  In  accordance  with  0MB  Circular  A-71,  the  sensitive 
information  systems  will  require  certification  at  the  completion  of 
systems  testing  by  the  information  systems  security  officer  or  agency 
official  designated  to  certify  that  the  systems  meet  the  documented  and 
approved  system  security  specifications,  meet  all  applicable  Federal 
policies,  regulations  and  standards,  and  that  test  results  demonstrate  that 
the  security  provisions  are  adequate. 

6.7  THE  SOFTWARE  CONVERSION 

Software  will  be  converted  in-house,  by  contractor,  or  a 
combination  of  the  two,  using  schedules  and  work  packages  developed 
during  planning  and  preparation  activities. 
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6.7.1  IN-HOUSE  CONVERSION 


The  first  source  programs  to  be  converted  should  be  the  most 
complex  or  those  that  have  been  frequently  modified.  Complex  programs 
force  project  team  members  to  become  thoroughly  familiar  with  the  new 
software  If  there  are  going  to  be  software  problems  which  could  result  in 
serious  slippage,  management  is  provided  an  early  awareness  of  this 
condition  and  can  apply  remedial  actions.  Frequently-modified  programs 
are  the  most  complex  as  a  result  of  the  modifications.  They  are  also 
normally  associated  with  information  systems  of  high  user  interest. 
Giving  these  priority,  converting  them  first,  and  placing  them  in  an 
operational  mode  avoids  user  pressures  to  incorporate  new  enhancements 
during  conversion. 

If  new  enhancements  cannot  be  avoided,  one  method  of 
minimizing  the  effect  of  modification  during  the  conversion  is  to 
implement  change  control  procedures  which  carefully  record  all  changes. 
Duplicate  work  packages,  go  the  the  project  team  and  the  other  to  the 
maintenance  programmeKs).  The  maintenance  programmers  continue  to 
make  changes  as  the  frozen  programs  are  converted.  Changes  to  the 
converted  program  are  added  later  (23). 

6.7.2  APPROACHES 

The  conversion  approaches  taken  by  the  project  team  are  team 
conversion,  individual  conversion  or  a  combination.  The  project  team 
members  will  employ  the  previously-decided  techniques  of  manually 
converting  code  on  a  line-for-line  basis,  reprogramming,  redesign,  the  use 
of  automated  tools,  or  a  combination  of  the  four  methods.  Selection  of 
the  approach  will  be  an  ^ency  management  decision  based  upon  available 
personnel  resources,  skills  and  experience,  time  available,  and  desired 
performance  of  the  converted  programs. 

6.7.2.1       Team  Conversion 

With  team  conversion,  each  member  of  the  team  is  assigned 
either  Control  Stream  Langue^e  (CSL),  data  files,  or  source  programs. 
One  person  or  group  of  people  is  in  chaise  of  converting  all  CSL,  another 
handles  all  data  files,  and  a  third  converts  all  source  programs.  The 
teams  differ  in  size  as  dictated  by  the  conversion  workload.  Also,  the 
skills  required  of  the  team  members  would  differ.  The  CSL  and  data  file 
teams  need  not  be  trained  in  application  program  languages,  e.g,  COBOL, 
Assembly  Lar^uage,  FORTRAN,  etc.  The  advantage  of  this  approach  is 
the  facility  in  developing  conversion  staff  skiUs.  Each  team  has  only  to 
become  experienced  in  specific  rather  than  broad  software  skill  areas. 
The  expertise  in  each  area  will  be  more  quickly  acquired  and  applied. 
Each  team  C6in  develop  expertise  in  the  other  areas  later,  as  time  permits. 
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6.7.2.2 


Individual  Approach 


With  the  individual  approach,  each  person  converts  all  aspects 
of  the  system  in  his/her  realm  of  responsibility:  CSL,  data  files,  and 
source  programs.  For  shared  data  files,  conversion  responsibility  should 
be  assigned  to  one  person.  The  advantt^e  of  this  approach  is  that 
individuals  become  familiar  with  the  total  requirements  of  the  individual 
systems.  The  responsible  person  can  often  anticipate  and  resolve  some 
problems  which  might  arise  based  on  this  insight.  The  disadvantage  of 
this  approach  is  that  it  takes  longer  to  develop  all  the  skills  associated 
with  system  conversion  rather  than  one  particular  area  of  expertise,  e.g., 
CSL. 

6.7.2.3       Modified  Approach 

The  modified  approach  is  a  combination  of  the  two.  An 
example  would  be  team  conversions  of  CSL  and  data  files.  Application 
programs  would  be  converted  by  a  functionally-knowledgeable  project 
team  member.  This  approach  permits  tailorir^  existing  resources  and 
skills  to  agency  conversion  needs. 

6.7.3  CONTRACTOR  CONVERSION 

With  contractor  conversion  of  the  source  code,  the  project 
manager  is  less  concerned  with  the  approach.  The  mans^ement  concerns, 
instead,  are  contract  management  and  issues  associated  with  timely 
delivery,  quality  and  documentation  of  software. 

6.7.4  QUALITY 

Converted  software  should  be  closely  reviewed  for  quality. 
The  pressures  on  personnel  during  conversion  to  meet  the  conversion 
schedule,  may  cause  project  team  members  to  retain  unnecessary  or 
unoptimized  code  (48).  The  conversion  phase  provides  the  opportunity  to 
develop  well  engineered  source  programs  based  on  modem  techniques  of 
software  engineering  (39,  42,  43).  It  is  also  an  opportunity  to  design  out 
old  routines  which  require  operator  intervention  but,  due  to  technical 
evolution  of  hardware,  are  not  applicable  on  the  new  system.  It  is 
particularly  important  for  contractually-converted  software  to  be 
examined  for  quality  and  performance  to  ensure  converted  systems 
execute  in  acceptable  run  times.  The  project  manager  should  regularly 
schedule  and  conduct  structured  walk-throughs  of  all  conversion  projects 
and  similarly  examine  contractually-converted  software. 

6.8  UNIT  AND  SYSTEMS  TESTING 

Initial  testing  is  normally  accomplished  in  two 
steps:  individual  application  program  and  file  (unit)  testing,  and  system 
testing  (see  Figure  6-3).  Managers  will  have  to  schedule  or  arrange 
supplies  and  paper  stock,  machine  time,  operators,  test  data,  system 
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programmers,  and  possibly,  during  systems  testing,  user  involvement. 
Test  criteria  should  be  established  beforehand.    The  test  criteria  should- 
include  performance  factors  that  relate  to  the  desired  level  of  quality,  be 
used  to  evaluate  individual  or  contractor   performance,  and  ensure  that 
cost-effective  results  are  being  obtained. 

6.8.1  UNIT  TESTING 

Individual  data  files  should  be  tested  to  ensure  that  they  have 
been  100  percent  converted.  Individual  application  programs  require 
testing  to  ensure  that  the  code  is  executed.  The  adequacy  of  this  testing 
depends  upon  the  quality  of  test  data.  The  ultimate  objective  is  100 
percent  testing  of  code  execution.  While  this  objective  is  realistically 
unattainable,  the  project  manner  is  encouraged  to  continually  refine  test 
data  towards  achieving  that  objective. 

6.8.2  SYSTEMS  TESTING 

After  unit  testing  of  programs  and  files  are  completed  they 
are  subjected  to  systems  testing.  The  purpose  of  this  testir^  is  to  ensure 
that  the  systems  operate  adequately  on  the  target  hardware.  Systems 
test  data  consist  of  representative  production  runs  with  appropriate 
performance  consideration  taken  into  account.  All  systems  document- 
ation should  be  written  in  an  acceptable  draft  state  by  the  end  of  systems 
testing.  Systems  testing  will  involve  information  systems  user 
participation  to  verify  the  acceptability  of  new  input  and  output 
procedures. 

6.8.3  TESTING  PROBLEMS 

6.8.3.1  Assembly  Language  and  Utilities 

Project  managers  should  be  prepared  to  handle  serious 
problems  during  systems  testing  if  the  agency  converts  from  Assembly 
Language  on  a  saturated  machine  or  has  made  extensive  use  of  vendor 
unique  utilities.  Unacceptable  run  times  can  occur  which  require  redesign 
or  extensive  reprogramming. 

6.8.3.2  Testing  Shortcuts 

Quality  test  data  is  extremely  important  and  difficult  to 
develop  and  maintain  (48).  Managers  should  resist  test  data  shortcuts  as 
an  expedient  of  avoiding  the  need  to  develop  different  test  packages, 
however. 

Unit  test  data  should  not  be  used  for  systems  testing.  Unit 
test  data  is  designed  to  exercise  the  converted  code.  The  systems  test 
data  is  derived  from,  and  represents  typical  production  runs.  The  test 
data  construction  is  different.  The  project  mane^er  should  also  resist 
accepting  code  for  systems  integration  testing  that  has  not  completely 
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fulfilled  unit  code  execution  tests.  The  manager  should  likewise  not  put 
code  into  a  parallel  testing  mode  that  has  not  been  fully  tested  and 
debugged  during  systems  testing.  Shortcuts  in  testing  due  to  pressures  of 
conversion  only  defer  problems  to  the  later  stages  of  software  conversion. 
Testing  problems  need  to  be  resolved  as  early  as  possible  to  preclude  an 
unmanageable  situation  in  which  cumulative  testing  problems  have  to  be 
addressed  and  solved  late  in  the  conversion  phase.  Unit  and  systems 
testing  reduce  to  a  minimum  software  problems  that  will  come  to  the 
attention  of  the  functional  user  during  parallel  testing.  A  low  incidence 
of  errors  in  production  runs  inspires  user  confidence  and  support. 

6.8.3.3       Production  Interference 

Because  it  is  difficult  to  forecast  exactly  the  machine  time 
and  other  resources  required  for  actual  testing,  management  will  have  to 
maintain  close  coordination  with  operations  personnel  and  users  to  gain 
their  support  and  cooperation  to  alleviate  unexpected  testing  problems 
that  place  an  unplanned  burden  on  normal  operations. 

6.9  PARALLEL  TESTING  AND  CROSSOVER 

Durir^  parallel  testing  the  project  manager  is  going  to  be 
concerned  with  running  the  old  and  new  systems  in  a  parallel  production 
mode  to  ensure  that  conversion  has  been  accomplished. 

A  management  problem  exists  for  those  applications  that  are 
infrequently  processed  (e.g,  fiscal  year  end  summaries).  It  may  be 
impractical  to  continue  parallel  testing  long  enough  to  compare  all  long 
term  applications.  The  objective  wiU  be  to  achieve  user's  confidence, 
crossover  to  the  new  system,  and  remove  the  old  hardware  in  order  to 
reduce  costs  associated  with  parallel  testing  or  back-up  processing.  When 
all  systems  have  been  or  are  undergoing  parallel  testing,  a  firm 
completion  date  must  be  established  to  force  an  end  to  the  conversion 
project. 

As  systems  complete  parallel  testing  it  is  important  that  users 
formally  acknowledge  acceptance.  This  provides  a  basis  of  understanding 
between  the  users  and  the  project  manager  that  conversion  of  the  systems 
has  been  successful. 

6.10  DOCUMENTATION 

The  project  manager  should  demand  software  documentation 
in  accordance  with  ^ency  or  FIPS  standards.  Managers  should  be 
especially  cautious  regarding  documentation  associated  with  that 
software  converted  by  a  contractor  (42).  The  normal  form  for  delivery  of 
contractually-converted  software  is  in  an  undocumented  state.  Managers 
should  anticipate  that  even  if  contracts  require  documentation,  the 
contractor  may  be  unfamiliar  with  documentation  standards,  may  have 
underestimated  resources  and  may  try  to  avoid  or  modify  contractual 
documentation  requirements. 
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6.11  CONVERSION  MANAGEMENT  DECISIONS 


The  conversion  phase  is  over  when  the  last  system  completes 
parallel  testing  and  documentation  is  completed.  Upon  assurance  that 
users  have  accepted  the  converted  information  systems,  agency 
executives  will  approve  project  management  recommendations  to 
implement  post-conversion  activities  to  restructure  the  software 
conversion  project  team  to  a  normal  operational  mode,  close  out  software 
conversion  contracts,  vacate  or  release  any  conversion  facilities  and 
equipment  no  longer  required,  and  to  conduct  a  post-conversion  analysis 
of  the  conversion  project. 

It  is  recommended  that  these  decisions  be  based  on 
recommendations  presented  as  part  of  a  formal  briefing  to  top  agency 
managers  and  information  system  users.  This  will  lend  assurance  that 
conversion  has  been  successfully  executed  and  keep  man^ement  informed 
of  the  conversion  activities  that  are  required  during  the  post-conversion 
phase. 

6.12  ECONOMIC  CONSIDERATIONS 

During  the  conversion  phase  the  major  elements  of  cost  will  be 
personnel-related.  Hardware  and  telecommunications  expenses  may 
become  significant  during  this  phase  for  file  and  program  conversion  and 
testing.  These  expenses  may  be  reflected  by  direct  hardware  rental  costs 
of  indirect  time-sharing  charges.  If  the  software  conversion  effort  uses 
existing  ADP  resources,  the  costs  of  these  resources  should  be  identified 
and  allocated  to  the  conversion  effort  on  a  fuU  cost-basis.  The  cost  of 
using  contractors  should  be  estimated  and  recorded  according  to  the 
detailed  cost  structure  approach  presented  in  Appendix  C.  In  this  manner, 
contractor  costs  should  be  detailed  by  cost  element;  i.e.,  personnel, 
facilities,  hardware,  overhead,  profit,  etc.  for  each  conversion  activity  or 
function,  and  not  given  as  a  lump  sum  contract  service  expense.  With  this 
cost  breakdown,  the  technical  evaluation  of  contractor's  performance  will 
be  possible. 

Actual  cost  performance  should  be  collected  and  recorded  in 
the  cost  structure  for  use  in  post-conversion  audits. 

The  use  of  the  software  conversion  cost  information  is  mainly 
in  the  tracking  of  project  costs  and  the  comparison  of  actual  cost  to  cost 
estimates  to  identify  significant  cost  variations.  Communications  with 
users  and  top  management  should  include  cost  information  such  as 
expenses  to-date,  budget  projections,  and  an  evaluation  of  the  cost- 
effectiveness  of  the  project.  Minor  charges  in  project  schedules  and  the 
allocation  of  in-house  or  contractor  resources  to  specific  tasks  should  be 
performed  with  consideration  of  cost  impacts.  This  project  refinement 
activity  should  include  an  assessment  of  each  alternative  on  the  full  cost 
of  conversion  in  order  to  address  the  lowest  total  overall  cost. 
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CONVERSION  PHASE  MANAGEMENT  CHECKLIST 


o       Conversion  team 

Located  in  facilities 

Requisite  skills  and  experience  available 

Team  members  aware  of  schedules,  duties  and 

responsibilities 

o       Interface  continuing  with 

Agency  executives 
Information  systems  users 
Hardware  operations  staff 
Contractor  project  officer 

o       Project  status  being  tracked 

o       Project  status  current 

o       Project  reports  current 

At  project  level 

At  agency  executive  level 

o       Training  being  accomplished 

New  hires  on  project  team 

Ad  hoc  to  users,  operators,  etc. 

o  Security 

Features  implemented  in  software;  verified 
Monitored  by  information  system  security  officer; 
users 

Software  certified  by  information  system  security 
officer,  lAW  0MB  Circular  A-71 
Most  complex  software  being  converted  fi''st 
Change     control     procedures     established  for 
conversion  of  software  with  new  enhancements 
Conversion  team  members  following  established 
security  procedures 

o       Contract  being   monitored;  quality   of  software  and 
documentation  assured 

o       Unit  and  systems  test  data  separate 

o       Files  100%  converted 
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Software  converted  to  level  of  acceptable  code 
execution 

Users  participating  in  systems  and  parallel  testing 

Close  interface  with  hardware  operations  staff  during 
testify 

Users  formally  accepting  systems  at  completion  of 
parallel  testing 

Firm  parallel  testing  end  date  established  to  force 
project  end 

Agency  executives  and  users  approve  end  of  the 
conversion  phase 

Agency  executives  approve  post  conversion  phase 
activities 

Settling  staff  into  normal  software  operations 
Close-out  contract 

Post  conversion  analyses  and  assessment 
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SECTION  7 


THE  POST-CONVERSION  PHASE 


Post-conversion  is  the  phase  of  a  software  conversion  life 
cycle  between  actual  conversions.  It  extends  for  an  indeterminate  but 
considerable  period  of  time,  generally  2  to  5  years,  depending  upon  the 
frequency  of  hardware  replacement.  This  phase  provides  the  best 
opportunities  to  learn  from  fresh  conversion  experiences  and  to  initiate 
actions  which  will  improve  the  utility  and  effectiveness  of  an  agency's 
software  and  concomitantly  facilitate  future  software  conversions. 

Additionally  the  true  costs  of  conversion  are  most  apparent  in 
this  phase  if  costs  have  been  tracked.  Differences  between  estimated  and 
actual  costs  can  be  identified  and  evaluated.  These  evaluations  can  then 
lead  to  better  cost  estimating  in  future  conversions. 

7.1  OBJECTIVES 

There  are  two  objectives  in  the  post-conversion  phase: 

o  Reestablish  the  agency  software  organization  in  a 
normal  operating  environment.  The  associated  activities 
are  to  complete  any  functions  from  the  software 
conversion  phase  which  remain  undone  (e.g., 
documentation,  completion  of  parallel  testing);  settle 
the  software  staff  in  a  normal  organizational  structure; 
and  begin  normal  software  maintenance  and  development 
actions. 

o  Develop  a  better  agency  posture  for  future  software 
conversions.  The  agency  should  conduct  a  post- 
conversion  assessment  of  the  conversion  experience; 
begin  planning  for  the  next  conversion;  and  initiate 
actions  which  will  cause  the  next  conversion  to  be  more 
effective  and  efficient. 

7.2  POST-CONVERSION  ACTIVITIES 

Figure  7-1  illustrates  the  major  activities  that  occur  during 
the  post-conversion  phase.  Many  of  these  activities  are  closely  related 
and  have  much  overlap,  particularly  those  that  pertain  to  the  post- 
conversion  analysis  and  assessment,  plsinning,  and  conversion  improvement 
techniques.  These  activities  provide  the  framework  for  subsequent 
discussions  in  this  section  which  provide  an  understanding  of  the  post- 
conversion  management  issues.  This  general  understanding  will  assist 
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managers  in  identifying  other  post-conversion  functions  that  pertain  to 
their  particular  agency  software  conversion  environment  and  form  a  base 
on  which  to  build  or  implement  actual  post-conversion  plans  and  actions 
to  improve  future  conversions. 

Post-conversion  activities  can  be  generally  grouped  into  three 

categories: 

o       Conversion  Termination/Transition  Activities 

These  are  transition  activities  between  a  conversion 
environment  and  a  normal  software  maintenance  and 
development  environment.  Typical  activities  include 
finishing  parallel  testing,  completing  documentation, 
closing  out  software  conversion  contracts,  disbanding  the 
project  team,  and  settling  the  agency  software  staff  into 
a  normal  software  organization  (e.g.,  systems 
programming,  maintenance  programming,  developmental 
programming). 

o       Post-Conversion  Analysis  and  Assessment  Activities 

These  activities  involve  conduct  of  a  thorough  review 
and  analysis  of  the  entire  conversion  experience  and 
preparation  of  a  formal  after-action  report.  This 
document  will  provide  managers  a  historical  perspective 
of  the  conversion,  and  assist  in  understanding  future 
conversions  and  ways  to  avoid  repetitious  mistakes.  It 
also  provides  a  reference  on  which  to  base  the  closely- 
related  activities  of  future  conversion  planning  and 
implementing  actions  to  improve  future  conversions. 

o       Future  Conversion  Planning  and  Conversion  Enhance- 
ment Techniques 

Early  initiation  of  future  conversion  planning  reinforces 
the  recent  conversion  lessons  learned  and  significantly 
improves  management's  ability  to  comprehend  all  the 
issues  of  future  conversion.  Management  can  also 
implement  and  enforce  many  techniques  and  procedures 
which  will  improve  the  quality  of  the  agency  software 
and,  at  the  same  time  increase  software  portability. 
These  methods  include  use  of  modern  software 
engineering  techniques  of  structured  design  and 
programming,  maintaining  current  documentation, 
avoiding  the  use  of  non-standard  programming  languages 
and  vendor  unique  utilities,  maintaining  high  quality  test 
data  and  files,  and  maintaining  disciplined  program  files 
and  data  bases. 


120 


7.3  CONVERSION  TERMINATION/TRANSITION  ACTIVITIES 


In  a  theoretical  conversion,  activities  associated  with  the 
conversion  phase  would  have  been  completed  before  the  post-conversion 
phase  began.  In  a  real  situation  activities  of  one  phase  extend  into 
another.  The  most  significant  on  going  functions  of  the  conversion  phase 
that  are  likely  to  extend  into  the  post-conversion  phase  are  parallel 
testing  and  documentation.  Activities  such  as  closing  out  contracts  and 
disbanding  the  conversion  team  wiU  be  more  transitionary.  Still  other 
activities  such  as  commencing  new  user  enhancements  postponed  until 
after  conversion  approach  true  post  conversion  activities. 

7.3.1  COMPLETION  OF  PARALLEL  TESTING 

Software  is  converted  on  a  prioritized,  scheduled  basis 
according  to  conversion  plans.  Thus,  in  the  initial  stages  of  the  post- 
conversion  phase  all  of  the  software  will  have  been  converted.  However, 
for  those  software  applications  converted  last,  some  residual  testing, 
particularly  parallel  testing,  wiU  likely  stiU  be  on  going. 

The  management  issue  here  is  to  strike  a  balance  between 
continuir^  parallel  testing  to  ensure  that  the  converted  software  meets 
functional  user  requirements,  while  at  the  same  time,  avoiding  protracted 
or  unduly  long  parallel  testing  and  operations.  Parallel  testing  is  costly  in 
terms  of  dollars  and  staff  resources.  As  long  as  parallel  testing  and 
operations  persist,  transition  to  a  normal  software  environment  cannot  be 
accomplished.  Therefore  managers  should  closely  examine  parallel 
testir^  with  a  continual  involvement  to  determine  if  the  seemingly 
endless  details  of  parallel  testing  outweigh  the  benefits  of  maintaining 
two  hardware  operating  environments.  Project  managers  may  have  lost 
the  perspective  to  make  this  judgement.  Upper  management  must  be 
prepared  to  exercise  "brute  force"  decisions  to  terminate  parallel  testing. 

7.3.2  DOCUMENTATION 

Software  documentation  should  be  written  concurrently  while 
converting  software.  However,  during  the  later  stages  of  the  software 
conversion  phase,  documentation  efforts  may  fall  behind  and  extend  into 
the  post-conversion  phase.  Also,  some  documentation  modifications  will 
be  required  due  to  changes  or  modifications  to  converted  software  as  a 
result  of  final  parallel  testing. 

Although  documentation  may  extend  into  the  post-conversion 
phase,  it  is  critical  that  management  ensure  completion  before  total 
transition  of  software  operations  to  a  normal  state.  Software  that  is  not 
documented  tends  to  remain  undocumented  and  this  creates  a  continuing 
source  of  problems  (23). 
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7.3.3 


CLOSING  OUT  CONTRACTS 


If  contract  services  have  been  used  to  convert  software  or  to 
augment  the  conversion  team  staff,  the  project  manager  will  be  involved 
in  contract  close-out  activities.  If  extensive  contractual  support  was 
used,  contract  close-out  will  be  significantly  aided  if  the  software 
conversion  project  management  team  has  a  full-time  COTR  to  assist  in 
contract  functions  (48). 

Contract  monitoring  should  have  been  an  ongoing  function 
throughout  the  conversion  process.  During  the  post-conversion  phase,  the 
Statement  Of  Work  (SOW)  should  be  reviewed  and  compared  with  the 
deliverables  to  ensure  that  contractual  obligations  have  been  met.  Actual 
cost  performance  should  be  compared  against  original  estimates  to 
determine  contractual  awards  or  penalties.  Software  deliverables  should 
also  be  examined  for  quality  and  fully  supported  by  documentation  that  is 
well  written,  usable  and  conforms  to  agency  standards  or  FIPS  PUB  38 
and  64. 

Contractual  issues  and  disputes  should  be  resolved  informally 
whenever  possible,  or  if  necessary,  formally  through  the  contracting 
office.  A  full  assessment  of  contractual  costs  and  obligations  should  be 
conducted  to  assure  that  the  agency  received  fuU  benefit  of  services  and 
to  surface  and  resolve  outstanding  cost  issues,  thus  avoiding  any  prolonged 
contractual  disputes  which  would  detract  from  normal  operations.  When 
all  contractual  issues  have  been  resolved,  the  contracting  office  should  be 
notified,  in  accordance  with  agency  procedures,  to  close-out  the  contract. 

The  key  management  concerns  are  to  ensure  that  contractual 
obligations  have  been  fulfilled,  and  potential  or  actual  problems  or  issues 
identified  and  resolved  as  expeditiously  as  possible  in  order  to  accomplish 
a  speedy  transition  to  normal  software  operations. 

7.3.4  DISBANDING  THE  PROJECT  TEAM 

As  parallel  testing  and  documentation  is  completed,  remaining 
members  of  the  project  team  should  be  released.  Those  team  members 
who  are  normally  part  of  the  agency  software  staff  will  revert  to  normal 
duties.  Since  large  scale  conversions  frequently  last  in  excess  of  one  year 
the  "normal"  duties  might  be  quite  new.  For  example,  personnel  turnover 
might  have  resulted  in  newly-hired  personnel  being  assigned  directly  to 
the  conversion  team.  For  these  people,  there  will  have  been  no  previous 
experience  in  agency  day-to-day  operations.  They  must  be  assisted  in 
adapting  to  the  normal  environment. 

Requirements  for  reorganization  of  the  agency  software  staff 
may  also  impact  disbanding  the  project  team.  Agency  growth  or 
functional  changes  may  have  altered  the  authorized  staffing  level  or  skill 
mix  of  the  software  staff.  Differences  in  the  source  and  target  computer 
systems  may  also  have  generated  a  need  to  restructure  the  software  staff. 
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Management  problems  in  settling  the  agency  software  staff 
into  a  normal  operational  mode  can  be  reduced  by  informing  all 
conversion  team  personnel  of  the  normal  agency  software  organization, 
and  providing  current  duty  descriptions,  and  internal  operating 
instructions.  Training  can  also  be  of  assistance  particularly  if  the  project 
members  worked  only  on  specialized  conversion  tasks  (e.g.,  only  converted 
job  stream  language). 

7.3.5  NEW  USER  ENHANCEMENTS 

User  information  system  enhancements,  deferred  until  after 
conversion,  will  commence.  Because  of  the  length  of  some  software 
conversions,  some  application  software  may  have  multiple  change 
requirements.  Information  system  software  changes  and  enhancements 
should  be  carefully  analyzed.  It  may  be  cost-effective  to  redesign 
systems,  and  to  incorporate  aii  cnanges  at  once,  rather  than  patching 
them  into  the  old  system  structures.  Also,  if  there  are  many 
enhancements  required,  priorities  will  have  to  be  established.  Priority 
assignments  will  require  functional  user  involvement  and  top  management 
decisions  and  support. 

The  management  issues  include  identifying  and  establishing 
priorities  for  developing  new  user  enhancements  and  determining  the  most 
cost-effective  approach  for  accomplishment.  Managers  should  also  ensure 
that  aU  software  changes  are  accompanied  by  appropriate  changes  in 
system  documentation. 

7.4  COST-TRACKING 

During  the  post-conversion  phase,  tracking  conversion  related 
costs  as  they  are  incurred  on  a  day-to-day  basis  is  important  to  reflect 
total  conversion  costs  in  the  post-conversion  analysis  and  assessment. 

Operational  cost  items  associated  with  the  post-conversion 
phase  include,  but  are  not  limited  to: 

o  Staffing  -  Staff  resources  devoted  to  conversion-related 
actions  as  opposed  to  normal  operations  (e.g.,  costs 
associated  with  disbanding  the  project  team  and 
resettling  the  normal  software  staff;  training). 

o  Contractual  -  Costs  associated  with  closing  out 
contractor  support. 

0  Computer  and  Facility  -  Costs  associated  with  residual 
conversion  functions  such  as  completion  of  parallel 
testing  and  residual  use  of  facilities  by  the  project  team. 
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o  Administrative  -  Costs  associated  with  clerical  and 
administrative  support  to  the  project  management  and 
project  teams;  particularly  the  administrative  support 
associated  with  the  post-conversion  analysis  and  assess- 
ment and  future  plan  development.  Documentation 
production  will  also  incur  administrative  costs. 

7.5  POST-CONVERSION  ANALYSIS  AND  ASSESSMENT 

One  of  the  most  important  post-conversion  functions  is  an 
analysis  of  the  entire  software  conversion  experience.  The  time  and 
resources  required  to  conduct  the  analysis  and  assessment  depend  upon 
the  magnitude  of  the  software  conversion  project.  A  medium  to  large 
conversion  project  assessment  might  involve  2-3  people  for  2-3  months. 
The  analysis  should  be  conducted  by  the  project  manager  and  the  project 
management  team  with  input  solicited  from  parties  that  had  an  important 
interest  or  role  in  the  software  conversion  (e.g.,  the  contractor,  project 
team,  hardware  acquisition  staff,  involved  functional  users).  The  most 
important  sources  should  be  conversion  history  logs  maintained  on  an 
ongoing  basis  during  the  software  conversion  and  the  knowledge  and 
experience  of  the  project  management  team  that  remained  intact  during 
the  entire  conversion  experience. 

It  is  important  that  the  post-conversion  be  conducted  in  a 
positive  manner.  It  should  not  simply  be  a  list  of  problems  or 
shortcomings  encountered  during  conversion.  The  assessment  should 
describe  the  entire  process  and  identify  those  procedures  that  were 
satisfactory  and  effective  as  well  as  those  that  were  less  than 
satisfactory.  It  should  offer  future  software  conversion  managers 
suggestions  and  recommendations  to  improve  their  conversion  efforts. 
The  assessment  should  identify  how  the  agency  can  plan,  now,  for  future 
conversions;  ongoing  software  practices  and  procedures  to  improve  future 
conversions;  and  other  actions  (e.g.,  policy  change  recommendations  ) 
which  may  be  required. 

7.5.1  POST  ANALYSIS  REPORT 

A  post-conversion  analysis  report  should  be  produced  as  a 
formal  document.  It  serves  four  important  agency  purposes. 

o       Historical  Reference 

The  report  provides  a  historical  reference  for  agency 
personnel  to  use  in  future  software  conversions.  The 
identification  of  problem  areas  and  solutions  should 
provide  future  software  conversion  managers  insight  and 
enable  them  to  better  manage  and  execute  a  software 
conversion. 
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o       Conversion  Costs 

The  report  displays  actual  conversion  costs.  If  the 
software  conversion  cost  structure,  detailed  in  Appendix 
C,  has  been  used  throughout  the  project,  the  report  will 
reflect  all  costs  including  those  frequently  overlooked  or 
disregarded  by  managers.  For  example,  the  costs  of 
assigned  staff  personnel,  particularly  those  involved  in 
conversion  part-time,  are  frequently  overlooked; 
conversion  costs  related  to  parallel  testing,  particularly 
with  government-owned  machines  are  not  fully 
considered;  the  full  extent  of  training  costs  (e.g., 
training  time)  tends  to  be  underestimated. 

o       Basis  for  Software  Conversion  Planning 

Planning  for  software  conversion  should  be  an  ongoing 
activity  and  not  solely  relegated  to  a  planning  phase 
immediately  preceding  an  actual  conversion.  Continued 
planning  for  the  eventual  software  conversion  can 
shorten  the  planning  time  span  when  a  conversion 
decision  is  made,  provide  more  detailed  and 
comprehensive  plans,  and  improve  the  overall  conversion 
process.  The  report  provides  insight  on  how  to  structure 
the  planning. 

o       Identify  Ongoing  Actions  or  Procedures  to  Improve 
Conversion 

There  are  many  actions  and  procedures  managers  can 
implement  and  enforce  which  will  improve  the  posture  of 
an  agency  to  conduct  a  cost-effective  conversion.  The 
report,  by  identifying  these  actions  and  their 
importance,  assists  agency  personnel  in  understanding 
the  need  for  these  procedures  and  encourages 
implementation. 

7.5.2  ANALYSIS  CONSIDERATIONS 

Elements  to  be  considered  in  the  post-conversion  assessment 
will  depend  upon  the  software  environment  of  the  particular  agency. 
However,  the  following  are  generally  applicable. 

o  Planning 

Adequacy  of  feasibility  study 
Adequacy  of  software  conversion  study 
Impact  of  other  studies  (e.g.,  A-76,  A-109) 
Adequacy  of  planning  time 
Sufficiency  of  detail 
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Adequacy  of  tracking  and  management  follow- 
through 

Adequacy  of  cost  estimates 

Planning  problems,  their  resolution  and  means  of 
avoidance 

Future  planning  requirements 

Staffing  and  Organization 

Adequacy  of  project  management  team 
Adequacy  of  project  team 
Skill  mix 

Proper  location  of  conversion  staff 

Adequacy  of  conversion  assignments  and  control 

Staffing     and     organization     problems,  their 

resolution,  and  means  of  avoidance 

Future  planning  requirements 

Use  of  Contractors 

Requirements  for  contractors 

Their  optimum  employment 

Adequacy  of  the  Request  for  Proposal 

Adequacy  of  contract  monitoring 

Adequacy  of  deliverables  and  services 

Contractor  problems,  their  resolution  and  means  of 

avoidance 

Future  planning  requirements 

Software  Conversion 

Selection,  use  and  adequacy  of  automated  tools  and 
techniques 

Conversion  of  languages 

Conversion  of  utilities  and  procedures 

Conversion  problems,  their  resolution  and  means  of 

avoidance 

Future  planning  needs 

Hardware  Staff  Interface 

Adequacy  of  hardware  acquisition  staff  interface 

Adequacy  of  conversion  support 

Conversion  problems,  their  resolution  and  means  of 

avoidance 

Future  planning  requirements 

Facilities 

Adequacy  of  facilities 

Success  in  single  site/dual  site  conversion 

Facility  requirements  and  use 
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Documentation 


Adequacy  of  pre-  and  post-conversion  documen- 
tation 

The  use  of  documentation 

Adequacy  of  agency  documentation  standards 

Documentation    problems,    their    resolution  and 

means  of  avoidance 

Future  planning  requirements 

Test  Data  and  Files 

Employment  of  test  data  and  files 

Adequacy  of  test  data  and  files 

Optimization  of  test  data  and  files 

Development  responsibility  for  test  data  and  files 

Test  data  and  file  problems,  their  resolution,  and 

means  of  avoidance 

Future  planning  requirements 

Training 

Adequacy  of  training 
Timeliness  of  training 
How  training  was  conducted 

Training  problems,  their  resolution  and  means  of 
avoidance 

Future  planning  requirements 
Security 

Agency  specific  security  and  privacy  requirements 
Adequacy    of    security    and    privacy  software 
conversion  activities 

Extent  of  unresolved  security  or  privacy  software 
issues 

Security  and  privacy  problems,  their  resolution, 
and  means  of  avoidance 
Future  planning  requirements 

Distributed  and  Remote  Sites 

Adequacy  of  planning 
Interface 

Adequacy  of  software  conversion 

Specific  problems,  their  resolution  and  means  of 

avoidance 

Future  pleuining  requirements 
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Telecom  munieations 


Adequacy  of  telecommunications  planning 
Adequacy  of  telecommunications  staff  support 
Conversion-related  problems,  resolution,  means  of 
avoidance 

Future  planning  considerations 

Top  Management  and  Functional  Users 

Their  support  of  conversion 
Freezing  development  of  new  user  enhancements 
Their  roles  and  involvement  in  conversion 
High    level    management   and   user  conversion- 
related  problems,  their  resolution,  and  means  of 
avoidance 

Future  planning  requirements 

Directives  and  Policy 

Adequacy  of  directives  and  policy 

Conflicts  in  directives  and  policy 

Responsibility  for  directives  and  policy  conflict 

resolution 

Future  planning  considerations 

Unforeseen  Problems 

Unforeseen  problems,  their  resolution,  and  means 
of  avoidance 

Future  planning  considerations 
Software  Conversion  Management 

If  not  otherwise  addressed,  cover  shortcomings  or 
support  from  software  conversion  management  that 
affected  other  related  projects  or  operations. 

Telecommunications 
Hardware  acquisition 
Hardware  operations 
Information  system  users 
Agency  executives 
Budgets  and  plans 

Costs 

Actual  conversion  costs  by  phase,  function  and  cost 
element 

Total  conversion  costs 
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Adequacy  and  source  of  funding 

Adequacy  of  budgeting 

Comparison  of  cost  estimates  to  actuals 

Adequacy  of  cost  analyses 

Cost  overrun  detail  and  reasons 

Conversion  cost  related  problems,  their  resolution 

and  means  of  avoidance 

Future  planning  considerations 

7.6  PLANNING    AND    INITIATING    ACTIONS    TO  IMPROVE 

FUTURE  CONVERSIONS 

Future  software  conversions  can  be  made  more  efficient  and 
effective  through  employment  of  a  combination  of  planning  and 
procedures  that  encourage  easily  maintainable  software  and  its 
conversion.  Some  activities  can  be  specifically  identified  as  pure  planning 
—  i.e.,  conversion  planning  input  into  agency  ADP  budget  submissions 
required  by  0MB  Circular  A-11.  This  is  long-range  planning.  At  the 
agency  software  operations  level,  some  software  conversion  improvement 
actions  will  be  planned  and  implemented.  This  is  technical  planning  and  it 
will  differ  among  agencies.  Practices  conducive  to  efficient  software 
conversion  such  as  disciplined  documentation  may  be  firmly  established 
and  on-going  at  one  agency  and  require  no  planning,  only  continued 
implementation.  At  another  agency,  however,  a  documentation  standards 
policy  may  have  to  be  planned  and  implemented.  If  managers  pursue  both 
long-range  and  technical  conversion  planning,  future  conversions  will  be 
much  simplified. 

7.6.1  LONG-RANGE  CONVERSION  PLANNING 

Long-range  planning  is  based  on  costs.  The  cost  estimatir^, 
analysis  and  tracking  experience  gained  in  the  recent  conversion,  if 
continually  refined  during  the  post  conversion  phase,  can  assist  managers 
in  estimating  correct  levels  of  conversion  resources.  If  the  project 
manager  has  been  following  a  total  cost  estimating  methodology  as 
recommended  in  Appendix  C,  the  structure  can  be  transferred  to  agency 
personnel  who  are  routinely  involved  in  long-range  planning. 

Planning  full  costing  methcJology  permits  an  agency  to 
analyze  costs  from  different  dimensions.  For  example,  costs  can  be 
developed  for  personnel,  by  phase,  year,  or  for  a  total  conversion  project. 
Alternatively,  all  costs  of  conversion  (e.g.,  personnel,  equipment,  etc.) 
can  be  developed  by  phase  or  by  year.  This  methodology  will  produce 
consistent  cost  estimates  from  whatever  perspective  they  are  examined 
(e.g.,  full  costs  of  programmers  will  result  in  the  same  total  if  they  are 
developed  by  year  or  by  phase).  This  consistency  results  in  significant 
advantages  for  an  agency  by  precluding  conflicting  cost  estimates  and 
providing  credibility  to  agency  plans,  studies  and  budgets. 
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7.6.1.1       Agency  Long-Range  Plans 


Office  of  Management  and  Budget  Circular  A-11  requires 
agencies  to  prepare  and  submit  annual  agency-wide  ADP  plans  which 
support  budget  estimate  submissions  covering  at  least  five  years.  Since 
federal  hardware  is  replaced  every  7-8  years  and  conversion  time  of  1-3 
years  are  incorporated  in  that  span,  software  conversion  planning  will  be 
required  in  the  majority  of  agency  plans. 

7.6.1.2  Input  To  GSA 

General  Services  Administration  CFR  Part  101-35  also 
requires  GSA  be  furnished  a  copy  of  the  agency  long-rar^e  plan  developed 
to  support  budget  submissions  with  supplementary  information  addressing: 

o  Trends  in  data  processing  workloads  that  will  or  may 
saturate  existing  ADP  systems  capabilities  prior  to 
expiration  of  the  anticipated  systems  life, 

o  Opportunities  to  take  advantage  of  cost-effective 
enhancements  brought  about  as  a  result  of  hardware 
technology  and  software  improvements, 

o  System  redesign  or  conversion  activities  planned  or  in 
process  to  improve  efficiency. 

This  supplementary  annual  input  to  GSA  illustrates  the  need  to 
maintain  continued  software  conversion  planning  based  on  costs.  AU  plans 
and  input  will  have  to  be  addressed  in  terms  of  cost  impacts. 

7.6.1.3  A-76  Studies 

ADP  is  considered  a  commercial  and  industrial  type  activity. 
0MB  Circular  A-76  requires  specific  evaluation  of  these  activities 
annually  as  well  as  at  the  time  of  major  change  to  determine  if 
government  ADP  services  and  functions  could  be  cost-effectively  assumed 
by  a  contractor.  Major  agency  conversions  or  hardware  acquisitions  are 
usually  preceded  by  an  A-76  study.  Software  conversion  planning  input 
based  on  full  costing  is  required. 

7.6.1.4  A-109  Studies 

An  agency  may  consider  a  hardware  replacement  a  major 
systems  acquisition  falling  under  the  provisions  of  0MB  Circular  A-109. 
Software  conversion  planning  input  will  be  required  to  develop  the  mission 
need  for  the  system,  analysis  of  alternatives,  and  selection  of  a  final 
system. 
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7.6.1.5 


The  Next  Conversion 


Ongoing,  long-term  planning  for  conversion  will  provide  the 
details  and  methodology  already  in  place  to  support  future  conversion 
feasibility  studies,  software  conversion  studies  and  conversion  planning. 
An  agency  will  thereby  be  in  a  position  to  complete  a  future  conversion 
project  in  a  much  shorter  time  span  than  required  for  current  projects. 

7.6.2  CONVERSION  TECHNICAL  PLANNING  AND  ACTIONS  TO 

IMPROVE  FUTURE  CONVERSIONS 

During  the  post-conversion  phase  many  actions  and  procedures 
can  be  planned  or  implemented  by  management  to  improve  future 
conversions.  These  procedures  should  be  either  established  agency 
practices  or  implementation  of  ongoing  conversion  plans.  Most  of  these 
procedures  are  synonymous  with  disciplined  software  management  and 
should  be  implemented  and  enforced  regardless  of  their  role  in  future 
conversions. 

The  f'^Uowing  technical  planning  considerations  that  can  be 
applied  or  enforced  during  the  post-conversion  phase  were  developed  from 
analysis  of  software  conversion  case  histories.  They  all  support 
portability  and  efficient  conversion. 

o  Software  Libraries  and  File  Maintenance.  Conversion 
planning  and  execution  is  often  complicated  by 
extraneous  and  outdated  programs,  files,  and  data  bases 
(e.g.,  outdated  systems,  old  test  files).  Software 
libraries  and  data  bases  require  disciplined  control  and 
purging  to  ease  actual  conversion  planning  and 
execution.  Such  purging  makes  maximum  effective  use 
of  hardware  facilities  on  a  routine  basis. 

o  User's  Support.  Rapport  and  understanding  must  be 
maintained  between  the  data  processing  staff  and  the 
functional  users.  This  reduces  user's  pressures  for 
introduction  of  new  enhancements  during  conversion. 

o  Top  Management  Support.  Executive-level  support  is 
required  during  conversion  to  provide  authority  to 
software  conversion  managers  and  assist  in  providing 
resources  to  complete  conversion  and  resolve  unforeseen 
problems.  The  ADP  managers  should  seek  some 
continuing  means  to  give  software  management  visibility 
during  the  post  conversion  phase.  Periodic  briefings, 
perhaps  at  six  months  intervals,  are  recommended. 

o  Training.  Continuous  training  of  the  data  processing 
staff  in  good  software  engineering  and  documentation 
techniques  promotes  routine  production  of  software  of 
high  technical  standards  as  well  as  portability. 
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Security.  Sensitive  systems  require  security  features  to 
be  carefully  considered  and  engineered  into  software. 
The  time  of  actual  conversion  does  not  provide  the 
optimum  environment  to  develop  security  specifications 
due  to  conversion  pressures.  Security  is  best  addressed 
systematicalUy  during  the  post  conversion  phase.  Then, 
security  features  are  already  engineered  into  software  at 
the  time  of  conversion. 

Documentation.  Adequate,  current  documentation,  in 
accordance  with  agency  standards  or  FIPS  PUB  38  or  64 
provides,  at  the  time  of  actual  conversion  planning, 
detailed  systems  information  needed  to  prioritize  and 
develop  schedules.  It  improves  understanding  of  system 
requirements  by  outside  personnel  who  assist  in  planning 
(e.g.,  contractors).  Documentation  facilitates  the 
efforts  of  those  actually  involved  in  conversion  duties. 

Standard  Languages.  Use  of  standard  languages,  by 
definition,  facilitates  portability  or  conversion  of 
software.  Vendors  offer  hardware  and  operating  systems 
that  accommodate  standard  languages.  Conversion  tools 
and  techniques  are  available  to  convert  standard 
languages.  Programmers,  analysts  and  consultants  are 
generally  familiar  with  standard  languages. 

Vendor  Unique  Utilities.  Reliance  on  vendor  unique 
utilities  degrades  portability  and  conversion.  Software 
staffs  should  be  discouraged  from  large-scale  use  of  such 
utilities. 

Software  Engineering.  Modern  techniques  of  structured 
software  design  and  development,  and  modular 
programming  facilitate  conversion  and  ease  of  software 
maintenance. 

File  Design.  Files  should  be  designed  for  ease  of  access 
by  standard  languages.  DBMS  should  be  employed  so 
that  they  can  be  supported  on  a  variety  of  common 
vendor  computer  systems. 

Test  Files  and  Data.  Test  files  and  data  require  design 
and  maintenance  to  ensure  that  quality  software  is 
developed  and  implemented.  This  quality  assurance  is 
required  during  software  maintenance  as  well  as  during 
conversion. 

Optimization.  Software  under  continuous  modification 
should  be  periodically  examined  for  efficiency  and 
optimized  as  required. 
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7.7  POST-CONVERSION  MANAGEMENT  DECISIONS 


There  are  two  major  management  decisions. 

First,  any  parallel  testing  which  continues  into  the  post- 
conversion  phase  must  be  terminated.  This  will  halt  costly  conversion 
activities  and  lead  to  restructuring  the  conversion  staff  into  an 
environment  conducive  to  routine  operations. 

Second,  the  post-conversion  analysis  and  assessment  report 
should  be  approved.  This  is  the  last  official  act  of  the  project  manager 
and  concludes  the  conversion  project.  Activities  continue,  however,  in 
planning  and  preparing  for  the  next  conversion. 

7.8  ECONOMIC  CONSIDERATIONS 

It  is  important  to  distinguish  between  the  identification  of 
software  conversion  costs  and  the  use  of  this  cost  information  as  it 
applies  to  this  phase.  In  order  to  provide  a  standard,  finite  definition  of 
software  conversion  for  cost  estimation  purposes,  the  cost  structure 
defined  in  Appendix  C  ends  with  appproval  of  the  post-conversion  analysis 
and  assessment  report.  Costs  will  include  significant  expenditures 
associated  with  settling  the  conversion  team  into  routine  software 
operations  (e.g.,  relocation  expenses  moving  from  temporary  real  estate, 
shipping  terminals  used  only  for  conversion).  Other  software  conversion 
costs  which  are  not  project-related  (e.g.,  long  term  planning)  incurred 
during  this  phase  will  not  be  estimated  in  the  software  conversion  cost 
structure. 

During  this  phase,  personnel  expenses  will  constitute  the 
majority  of  the  total  cost  as  manpower  is  expanded  to  perform  the  post- 
conversion  analysis  and  assessment.  Additional  cost  areas  that  may  be 
significant  during  this  phase  include  relocation  expenses  for  the 
conversion  staff  and  freight  and  transportation  expenses  for  the  office 
furnishings.  If  equipment  acquired  for  the  conversion  effort  is  released,  a 
reasonable  residual  value  for  the  equipment  should  be  credited  to  the 
total  software  conversion  cost. 

The  use  of  the  software  conversion  cost  information  during  the 
post-conversion  phase  will  require  a  review  of  both  estimated  and  actual 
costs  accumulated  over  the  life  of  the  project.  Analysis  of  cost  results 
should  address  areas  such  as  the  amount  and  degree  of  deviation  between 
estimated  and  actual  costs,  specific  areas  of  cost  deviation  identified 
through  the  use  of  a  detailed  cost  structure,  and  the  validation  of  cost 
estimation  techniques  and  models.  The  actual  cost  information  recorded 
can  provide  a  basis  for  evaluating  the  effectiveness  of  conversion  tools 
and  may  be  used  to  prepare  recommendations  for  improved  procedures 
that  can  increase  the  cost-effectiveness  of  software  conversion. 
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POST  CONVERSION  MANAGEMENT  CHECKLIST 

o       Parallel  testing  terminated 

o       Documentation  completed 

o       Conversion  staff  reverted  to  normal  duties 

Informed  of  organization 
Informed  of  duties 
Trained  as  necessary 
o       Contracts  closed  out 

SOW  reviewed 

Obligations  met 

Cost  issues  (if  any)  resolved 

o       Unneeded  conversion  facilities  released 

o       New  user  enhancements  pending  changes  analyzed  for 
redesign 

o       Ongoing  costs  being  tracked 
o       Post-conversion  analysis  completed 
Report  complete 

Support  planning  and  future  conversion 
Coordinated  with  staff  ^ 
Approved 

o       Project  manager  released 

o       Ongoing    long-term    planning    based    on    full  cost 
methodology;  adequate  to  support 

A-76  Studies 
A-109  Studies 
A-11  Planning 
Budget 

Future  conversion 

o       Conversion  technical  planning  ongoing 

o       Conversion  technical  plans  implemented  to  promote 
efficient,  portable  software 

Software  library  maintenance  and  purging 
File  maintenance  and  purging 
Continuous  user  interface 
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Continuous  top  executive  interface  and  reporting 

Training  supporting  good  software  practices 

Security  requirements  regularly  addressed 

Documentation  procedures 

Standard  language  used 

Vendor  unique  utilities  discouraged 

Software  engineering  practices 

Files  designed  for  standard  language  access 

Test  files  and  data  maintained  and  used 

Regular  optimization  of  software 
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The  following  references  should  be  part  of  any  software 
conversion  manager's  library. 

FEDERAL  DIRECTIVES: 

FPR  1-4.11  Procurement  and  Contracting  Government-Wide  for 
Automatic  Data  Processing  Equipment,  Software,  Maintenance  Services 
and  Supplies.  This  regulation  defines  procurement  and  contracting 
policies  relating  to  the  acquisition  of  hardware,  software,  maintenance 
and  supplies  for  A  DP. 

FPMR  101-35  ADP  and  Telecommunications  Management  Policy.  This 
regulation  establishes  the  general  policies  and  procedures  relative  to  the 
acquisition,  management  and  utilization  of  ADP  equipment,  software, 
maintenance  and  supplies. 

FPMR  101-36  ADP  Management.  This  regulation  defines  the 
requirements,  policies  and  procedures  governing  the  use,  utilization  and 
management  of  government  ADP  facilities. 

FPMR  101-37  Telecom munciations  Management.  This  part  prescribes 
policies  and  procedures  governing  the  utilization  of  telecommunication 
services  by  Federal  agencies. 

FPMR  Temp.  Reg.  F-496  Federal  Conversion  Support  Center.  This 
temporary  regulation  advises  agencies  of  the  reimbursable  services 
provided  by  the  Federal  Conversion  Suport  Center  (FCSC)  for  ADPE  and 
teleprocessing  services,  software  conversion  support  assistance,  guidance, 
and  support.  This  regulation  replace  FPMR  Temporary  Regulation  F-492, 
October  18,  1979,  in  that  it  removes  the  F-492  requirement  for  FCSC 
evaluation  reports  on  conversion  studies. 

Public  Law  89-306  Federal  Property  and  Administrative  Services  Act  of 
1949  (as  amended  by  the  Brooks  Act,  October  30,  1965).  This  Act 
establishes  the  authority  to  provide  for  improved  and  efficient 
procurement,  maintenance,  operation  and  utilization  of  ADP  equipment. 
It  also  establishes  an  ADP  fund  for  use  by  Federal  agencies. 

Public  Law  96-511  Paperwork  Reduction  Act  of  1980.  December  11, 
1980.  The  purpose  of  this  Act  is  to  reduce  paperwork  and  enhance  the 
efficiency  of  the  Government.  Specifically  it  calls  for  the  improvement 
and  increased  efficiency  in  the  use  of  ADP  and  telecommunication 
services. 

STANDARDS  AND  GUIDELINES: 

National  Bureau  of  Standards.  FIPS  PUB  31.  Guidelines  for  Automatic 
Data  Processing  Physical  Security  and  Risk  Management.  June  1974.  A 
handbook  for  structuring  physical  security  and  risk  management  programs 
for  ADP  facilities. 
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National  Bureau  of  Standards.  FIPS  PUB  38.  Guidelines  for 
Documentation  of  Computer  Programs  and  Automated  Data  Systems. 
February  15,  1976.  This  guidelines  provides  a  basic  reference  and 
checklist  for  determining  the  content  and  extent  of  documentation  of 
software  programs. 

National  Bureau  of  Standards.  FIPS  PUB  41.  Computer  Security 
Guidelines  for  Implementing  the  Privacy  Act  of  1974.  May  30,  1975.  This 
publication  provides  guidelines  for  implementing  computer  safeguards 
(i.e.,  management  of  information,  system/network  controls,  and  physical 
security)  as  mandated  by  Public  Law  93-579,  the  Privacy  Act  of  1974. 

National  Bureau  of  Standards.  FIPS  PUB  48.  Evaluation  of  Techniques 
for  Automated  Personal  Identification.  April  1977.  Discusses  techniques 
for  identifying  individuals  seeking  access  to  computer  systems. 

National  Bureau  of  Standards.  FIPS  PUB  64.  Guidelines  for 
Documentation  of  Computer  Programs  and  Automated  Data  Systems  for 
the  Initiation  Phase.  August  1,  1979.  This  guideline  provides  a  basic 
reference  and  checklist  for  determining  the  content  and  scope  of 
documentation  for  the  initiation  phase  (feasibility,  cost/benefit  analysis) 
of  a  software  life  cycle. 

National  Bureau  of  Standards.  FIPS  PUB  65.  Guidelines  for  Automatic 
Data  Processing  Risk  Analysis.  August  1979.  Presents  a  technique  for 
conducting  a  risk  analysis  of  an  ADP  facility  and  related  assets. 

National  Bureau  of  Standards.  FIPS  PUB  73.  Guideline  for  Security  of 
Computer  Applications.  June  1980.  These  guidelines  describe  methods 
and  techniques  that  can  reduce  the  hazards  associated  with  computer 
applications. 

Executive  Office  of  the  President,  Office  of  Management  and  Budget, 
Circular  No.  A  76,  Policies  for  Acquiring  Commercial  or  Industrial 
Products  and  Services  for  Government  Use.  This  policy  document 
prescribes  evaluation  of  government  run  operations,  at  time  of  major 
change  (such  as  software  conversion),  to  determine  if  operations  can  cost- 
effectively  be  transferred  to  contractor  support. 

Executive  Office  of  the  President,  Office  of  Managfement  and  Budget, 
Circular  No.  A  109,  Major  Systems  Acquisition.  This  policy  document 
requires  studies  to  be  performed  in  a  prescribed  method  when  acquiring 
major  systems,  includir^  large  computer  systems. 
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REFERENCES: 


General  Accounting  Office.  Conversion;  A  Costly,  Disruptive  Process 
That  Must  Be  Considered  When  Buying  Computers.  A  report  to  the 
Chairman,  Committee  on  Appropriations,  House  of  Representatives. 
FGMSD  D-80-35.  June  3,  1980.  This  report  summarizes  GAO's  findings 
on  the  treatment  of  software  conversion  costs  in  evaluating  vendor 
proposals. 

General  Accounting  Office.  Millions  in  Savings  Possible  in  Converting 
Programs  from  One  Computer  to  Another.  FGMSD-77-34  (1977).  This 
report  is  a  survey  and  management  review  of  several  agency  conversions 
and  their  problem  areas. 

General  Services  Administration.  Conversion  Products/Aids  Survey. 
Federal  Conversion  Support  Center.  Report  No.  GSA/FCSC-80/01. 
August  1980.  This  report  describes  in  detail  many  of  the  commercially 
available  automated  conversion  packages  and  aids  currently  available  to 
the  Government. 

General  Services  Administration.  Conversion  Study  Outline.  Federal 
Conversion  Support  Center.  August  1980.  This  document  provides  a 
checklist  for  identifying  and  cataloging  source  programs  and  data  files 
subject  to  conversion. 

General  Services  Administration.  Review  and  Analysis  of  Conversion 
Cost-Estimating  Techniques.  Federal  Conversion  Support  Center.  Report 
No.  GSA/FCSC-81/001.  April  1981.  This  document  identifies  and 
evaluates  seven  conversion  cost  estimating  techniques  available  to 
agencies.  Each  technique  is  briefly  examined  in  terms  of  its  advantages 
and  disadvantages. 

National  Bureau  of  Standards.  Conversion  of  Federal  ADP  Systems:  A 
Tutorial  Special  Publication  500-62.  August  1980.  This  document 
presents  in  tutorial  fashion  an  analysis  of  several  recent  conversion 
projects  with  observations  and  salient  problem  areas  identified.  Several 
case  studies  are  included. 

U.S.  Army.  Army  Automation  Planning  Guide  for  Software  Conversion. 
Technical  Bulletin  18-122.  October  1977.  This  report  presents  a  detailed 
outline  of  the  conversion  preparation  process  including  both  pre-award 
and  post-award  activities. 


144 


APPENDIX  C 
SOFTWARE  CONVERSION  COSTING 


145 


APPENDIX  C 


SOFTWARE  CONVERSION  COSTING 


The  information  contained  in  this  appendix  has  been  developed 
to  provide  guidance  for  the  practical  application  of  the  conc^t  of  full 
costing  to  the  management  of  software  conversion  projects  The  purpose 
of  this  appendix  is  to  define  the  approach,  or  methodology,  that  should  be 
followed  in  developing  software  conversion  costs.  The  approach  presented 
is  intended  to  be  a  generalized  methodology  and  attempts  to  discuss  cost 
considerations  in  general  terms  This  total  system  approach  can  then  be 
modified,  as  appropriate,  to  fulfill  the  specific  costing  requirements  of 
each  software  conversion  project. 

It  is  important  to  understand  the  steps  for  developing  a  total 
conversion  costing  methodology.  The  methodology  consists  of  two  parts. 
The  first  is  the  definition  of  fuU  conversion  costs  which  requires: 

o       Identification  of  project  characteristics, 

o       Development  of  the  full  cost  structure, 

o       Estimation  of  the  cost  data, 

o       Analysis  of  the  cost  data. 

The  second  part  is  the  application  of  the  cost  data  to  support 
management  decisions.  The  remainder  of  this  appendix  describes  these 
steps  in  more  detail  It  is  important,  however,  to  continue  to  view  costing 
in  terms  of  a  total  methodology,  to  assure  that  the  maximum  return  is 
obtained  from  the  costing  development  effort. 

C.l  INTRODUCTION 

Software  conversion  project  managers  are  required  to  prepare 
budgets,  monitor  the  progress  of  programs  and  projects,  estimate  the  cost 
of  new  capabilities,  and  make  a  variety  of  other  system-related  decisions 
on  a  frequent  basis  It  is  the  objective  of  this  appendix  to  provide  a 
consistent  cost  methodology  that  can  assist  the  project  manager  by 
ensuring  that  the  required  conversion  cost  data  is  both  available  and 
reliable.  Also,  by  providing  a  consistent  costing  methodology,  historical 
costs  can  be  uniformly  accumulated  and  updated  to  increase  the  accuracy 
of  future  estimates. 

C.1.1  SCOPE  OF  THIS  METHODOLOGY 

The  identification  of  software  conversion  costs  addressed  in 
this  appendix  includes  all  major  cost  factors  directly  attributable  to  a 
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software  conversion  effort.  The  software  conversion  project  may  be 
conducted  as  part  of  a  total  hardware  installation  effort,  with  planning, 
analysis  and  implementation  tasks  being  conducted  concurrently.  The 
scope  of  this  appendix,  however,  will  be  limited  to  the  software 
conversion  effort  which  is  just  one  major  factor  in  that  hardware 
transition  effort  Other  hardware-related  costs  such  as  site  preparation, 
installation,  and  ongoing  operations  will  not  be  included.  Identification  of 
software  conversion  costs  will  include  both  direct  and  indirect  costs  that 
can  be  identified  with  the  conversion  effort,  and  may  span  organizational 
boundaries  and  include  the  user  community  costs. 

If  the  software  conversion  is  accompanying  hardware  replace- 
ment, the  costing  of  the  software  conversion  effort  should  form  an 
important  input  into  the  life  cycle  cost  (LCC)  of  the  total  acquisition 
effort.  The  total  LCC  should  include  the  total  cost  of  acquiring, 
installing  and  operating  the  ADP  system  from  the  inception  of  the 
acquisition  process  until  the  system  becomes  obsolete.  The  development 
of  accurate  and  detailed  software  conversion  cost  estimates  will  not  only 
aid  the  conversion  project  decisions  but  will  also  aid  in  the  selection  of 
the  total  system  acquisition  alternatives.  The  software  conversion 
project  manager  should  assure  that  a  single  cost  estimation  effort  is 
conducted  where  software  conversion  cost  estimates  are  supplied  to  the 
total  acquisition  LCC,  and  where  acquisition  decisions  are  communicated 
to  the  conversion  project  to  be  reflected  in  the  software  conversion  cost 
estimates.  This  sharing  of  cost  information  can  prevent  situations  where 
ambiguous  and  conflicting  costs  are  reported  to  upper  management 

C.1.2  CONVERSION  COST  DEFINITION 

The  first  step  in  the  understanding  of  the  conversion  costing 
methodology  is  the  definition  of  conversion  costs.  This  can  be 
accomplished  by  identifying  the  full  cost  structure  that  represents  the 
software  conversion  effort,  and  by  defining  the  length  of  the  software 
conversion  cycle.  1 

C.1.2 .1       FuU  Costing 

FuU  costs  of  a  software  conversion  include  the  obvious  direct 
costs  of  ADP  employees  and  software  conversion  tools  Indirect  overhead 
costs  such  as  space  rental,  ADP  management  and  support  costs  can  also 
be  identified  or  reasonably  allocated  to  a  particular  conversion  effort, 
especially  if  the  costs  are  incurred  within  a  particular  agency.  The 
biggest  problem  of  defining  the  full  costs  of  a  system  occurs  in  the  user 
community,  or  in  organizations  beyond  the  control  of  the  ADP  facility 
management  or  even  the  agency  management. 

C.1.2 .2       Conversion  Cycle  Length 

The  length  of  the  software  conversion  cycle  depends  upon  the 
beginning  point,  when  costs  begin  to  accumulate,    until  the  project  has 
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been  completed.  The  following  factors  should  be  considered  in 
determining  the  project  cycle  length: 

o  Beginning  Point  -  For  the  purpose  of  this  appendix,  the 
beginning  event  for  the  estimation  of  costs  is  assumed  to 
occur  with  the  appointment  of  a  conversion  project 
manager.  This  point  does  not  necessarily  coincide  with 
the  beginning  of  the  software  conversion  effort  since 
software  conversion  has  a  continuous  life  cycle.  Each 
life  cycle  has  a  distinct  project,  however,  and 
development  of  project  costs  is  the  important  issue. 
With  the  appointment  of  a  project  manager: 

Costs  can  be  clearly  identified  with  a  particular 
project,  and. 

Accountability  for  costs  has  been  clearly 
established. 

If,  for  some  reason,  significant  project-related  costs 
have  been  incurred  prior  to  the  appointment  of  a  project 
manager,  these  costs  should  be  retained  in  the  historical 
cost  records. 

o  Ending  Point  -  For  cost  estimation  purposes,  the 
software  conversion  project  ends  when  conversion  has 
been  completed,  conversion  resources  have  been 
reassigned  and  the  post-conversion  audit  and  analysis 
have  been  completed. 

The  subject  of  costing  —  its  definition,  estimation  and  use  by 
project  management  —  has  no  single,  cookbook  approach  that  can  be 
applied  for  all  projects.  Instead,  what  is  needed  is  a  methodology  that 
addresses  the  costing  requirements  of  management  in  general,  and  the 
guidance  that  can  mold  the  methodology  to  the  individual  needs  of  each 
project.  This  is  the  approach  taken  by  this  appendix. 

C.2  CONVERSION  COSTING  METHODOLOGY 

The  process  to  be  followed  in  identifying  the  full  cost  of  the  conversion 
effort  is  illustrated  in  Figure  C-1.  The  major  steps  in  this  process 
include: 

o  Characterization  of  the  Conversion  Effort  -  This 
includes  a  general  understanding  of  the  project  goals  and 
objectives,  source  environment,  potential  target  environ- 
ments, current  software  inventory  and  inventory  status. 
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o  Definition  of  a  Cost  Structure  -  The  cost  structure 
should  reflect  the  requirement  for  more  detailed  cost 
information  as  the  project  progresses  and  should  include 
major  categories  of  cost 

o  Estimation  of  Costs  -  Defined  by  the  cost  structure  using 
resource  and  price  estimates  developed  from  historical 
data,  models,  price  lists,  industry  sources,  etc. 

o  Analysis  of  the  Cost  Data  -  Specific  analysis  objectives 
are  based  on  the  requirements  for  the  use  of  cost  data  by 
project  management 

o  Application  of  the  Cost  Data  -  To  provide  specific  cost 
input  for  costing  decisions  and  activities. 

Each  of  these  steps  is  described  in  more  detail  in  the  sections  that  follow. 

C.3  CONVERSION  PROJECT  CHARACTERIZATION 

The  characterization  of  the  conversion  effort  is  an  important 
preliminary  step  in  the  execution  of  the  conversion  costing  methodology. 
Through  a  thorough  evaluation  of  the  major  characteristics  of  the 
conversion  project,  a  cost  structure  can  be  developed  that  reflects  the 
material  costs  expected  to  be  incurred  and  allows  for  the  application  of 
costs,  with  sufficient  detail,  to  fulfill  expected  management 
requirements. 

A  conversion  project  may  be  characterized  using  several 
factors  including: 

o  Software  environment,  e.g.,  current  languages  used, 
whether  they  are  in  standard  ANSI  language,  degree  of 
documentation, 

o  Multiplicity,  e.g.,  whether  the  conversion  involves 
multiple  sites,  systems,  or  user  organizations, 

o  Financial  impact,  e.g.,  whether  the  expected  dollar  size 
of  project  will  require  increased  reporting  efforts, 

o  Mission  supported,  e.g.,  whether  workload  cycles  will 
restrict  the  project  schedule. 

This  characterization  step  should  result  in  an  informal,  written 
understanding  of  the  relevant  project  characteristics  stated  in  terms  of 
the  project's  goals  and  objectives.  This  understanding  should  be  approved 
by  the  project  manager  during  project  initiation  in  the  development  of  a 
conversion  cost  structure.  This  understanding  should  also  be  reviewed 
periodically  throi^hout  the  project  and  revised  as  needed. 
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C.4  COST  STRUCTURE  DEFINITION 


The  primary  component  of  the  methodology  is  the  design  of  a 
comprehensive  cost  structure  that  addresses  the  full  cost  of  the 
conversion,  aids  in  the  estimation  of  conversion  resource  requirements 
and  price  factors,  and  allows  the  application  of  a  single  cost  information 
base  to  several  project  costing  needs.  The  cost  structure  defined  in  this 
appendix  meets  these  requirements  through  the  use  of  cost  dimensions. 

A  cost  dimension  is  a  classification  scheme  that  identifies  a 
particular  characteristic  of  an  entire  project.  For  example,  project  costs 
may  be  recorded  as  follows:  personnel  $75,000,  equipment  $10,000, 
facilities  $10,000,  miscellaneous  $5,000  The  cost  of  the  project  may  also 
be  defined  along  functional  terms,  such  as,  conversion  $80,000,  training 
$12,000  and  administration  $8,000  In  a  similar  fashion  the  total  project 
cost  could  be  divided  into  cost  per  phase,  cost  per  year  and  so  forth.  In 
each  case,  a  summation  of  costs  along  any  dimension  would  yield  the  same 
result,  or  in  this  example,  $100,000. 

The  purpose  of  the  dimensional  cost  structure  is  to  minimize 
cost  ambiguities  in  addition  to  providing  the  following: 

o       Assistance  in  defining  the  fuU  cost  of  a  project, 
o       A  work  breakdown  for  ease  of  cost  estimation,  and 
o       Detailed     cost     information    for    use    by  project 
management. 

The  full  cost  of  a  project  can  be  defined  using  single 
dimensions  and,  similarly,  a  summation  of  costs  along  each  dimension 
would  yield  the  same  full  cost  figure.  The  benefit  of  a  dimensional 
approach  is  the  ability  to  identify  categories  of  cost  (such  as  software 
conversion  personnel  costs)  that  span  several  dimensions.  The  following 
dimensions  diould  be  included  in  the  software  conversion  cost  structure: 

C.4.1  COST  ELEMENT  DIMENSION 

Cost  elements  correspond  to  the  basic  accounting  units  that 
represent  personnel,  material  and  facilities  The  cost  element  dimension 
has  been  developed  for  this  cost  structure  using  ADP  terminology  and 
providing  a  level  of  detail  that  is  consistent  with  the  amount  of  funds 
normally  expended  for  each  category.  It  is  the  responsibility  of  each 
project  manager,  working  with  the  cost  analyst,  to  identify  the  cost 
element  level  of  detail  that  reflects  the  characteristics  of  the  project  and 
supports  the  application  of  the  conversion  costir^  methodology  to  the 
project's  needs. 

The  cost  element  detail  that  follows  is  illustrated  in  Figure  C-", 
and  should  be  viewed  as  general  guidance.  Important  cost  areas  may  be 
expanded  if  they  are  material  to  the  decisions  supported  by  the  costing 
methodology.      Elimination    or    consolidation    of    the    cost  element 
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dimensional  detail  should  be  done  only  with  careful  consideration  as  to  the 
impact  on  the  cost  estimation  techniques  and  the  ultimate  application 
potential  of  the  resulting  structure. 

The  following  is  a  definition  of  each  significant  cost  element: 

o  Personnel  -  The  personnel  cost  element  will  normally  be 
common  to  each  software  conversion  project  and 
account  for  a  s^nificant  portion  of  the  costs.  Personnel 
costs  are  also  the  most  likely  to  be  underestimated 
either  through  an  incomplete  definition  of  the  work  to  be 
performed,  quantity  of  personnel  required,  level  and  cost 
of  skills  required,  or  amount  of  ancillary  personnel  costs. 
The  personnel  cost  element  consists  of  the  following  sub- 
elements: 

Compensation  -  includes  base  wages,  cash  awards, 
overtime  pay  and  premium  pay  in  the  form  of  shift 
differentials,  incentive  pay,  merit  pay,  and  other 
allowances  for  all  regular,  part-time,  permanent 
and  temporary  employees. 

General  Benefits  -  includes  employer-paid  medical, 
dental,  life  and  disability  insurance,  and 
contribution  to  non-social  security  retirement 
plans,  federal  and  locally-imposed  payroll  taxes 
such  as  FICA  ^social  security),  FUTA 
(unemployment),  and  workman's  compensation 
taxes;  and  other  benefits  such  as  professional  dues 
and  member^ips,  subscriptions,  awards,  uniform 
cost  and  cleaning,  and  any  other  personnel 
expenses  that  are  not  otherwise  described. 

Training  Expenses  -  includes  expenditures  for 
tuition,  fees,  educational  books,  materials  and 
training  aids. 

Travel  and  Transportation  Expenses  -  includes  the 
transportation  of  employees  for  business,  training 
or  relocation  purposes.  It  includes  actual 
transportation  expenses  for  auto,  airlines,  bus,  and 
train  travel,  as  well  as  meals,  lodging,  tolls,  tips 
and  other  travel  expenses. 

Hiring/Separation  Expenses  -  includes  advertising 
costs,  credit/background  investigations  fees, 
employment  agency  fees,  testing  service  fees,  and 
outplacement  fees. 
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Moving  Expenses  -  includes  the  cost  of  transporting 
personal  property  such  as  the  shipment  of 
household  goods,  property  storage,  closing  costs 
and  mortg^e  interest  adjustments. 

In  addition  to  the  personnel  cost  categories  listed  above,  it 
may  be  beneficial  to  be  able  to  identify  personnel  salaries  based  upon 
individual  skill  categories.  This  process  will  assist  in  the  estimation  of 
salary  expense  by  providing  common  job  titles,  and  will  aid  in  the 
application  of  the  costing  methodology  for  alternative  evaluation 
purposes.  A  personnel  skills  category  definition  would  be  applied  to  the 
salary  cost  element  and,  in  the  federal  government,  would  contain  costs 
by  jdo  title,  GS  level  and  GS  step. 

o  ADP  Hardware  -  ADP  hardware  expenses  may  be 
incurred  during  the  software  conversion  effort  in  terms 
of  CPU  hours  purchased  from  a  service  bureau  or 
provided  by  the  equipment  vendor,  or  target  equipment 
obtained  on  a  short-term  basis  to  provide  the  test 
environment  and  on-line  conversion  capabilities  required 
during  the  project.  Subelements  of  this  category 
include: 

Operating  Unit  -  includes  the  mainframe,  operator 
consoles,  storage  and  memory  devices  acquired  for 
the  project. 

Data  Entry  Devices  -  includes  the  terminals  and 
other  input  equipment. 

Timesharing  Service  -  includes  the  cost  of 
timesharing  services  used  during  the  project, 

Equipment  Maintenance  -  includes  the  cost  of 
normal  hardware  maintenance  service  contracts, 

Other  ADPE  -  includes  ADP  equipment  not 
included  above,  such  as  tape  cleaners,  hardware 
monitors,  test  equipment,  and  spare  parts. 

o  ADP  Software  -  ADP  software  includes  an  ever- 
increasing  proportion  of  ADP  costs  as  data  processing 
installations  use  more  canned  programs,  and  less  in- 
house  software  is  developed  This  cost  element  includes 
only  purchased  or  leased  software.  ADP  software 
includes  the  subelements  of: 

Operating  Systems  -  includes  the  mainframe 
operating  software  including  spooling  software. 
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Conversion  Support  Software  -  includes  the  system 
support  software  such  as  compilers,  utilities, 
translators,  and  tools, 

General  Purpose  Software  -  includes  multi-use 
software  such  as  SAS,  SPSS,  RPG,  etc.. 

Software  Documentation  -  includes  the  manuals, 
guides,  and  software  handbooks  obtained  for  use 
with  the  ADP  software. 

Software  Maintenance  Service  -  includes  the  cost 
of  normal  software  maintenance  service  contracts, 

Other  software  -  includes  other  software-related 
costs. 


Telecommunications  -  The  telecommunications  cost 
element  includes  the  hardware  and  service  required  to 
provide  data  communications  between  ADPE  components 
to  support  software  conversion  This  element  includes 
the  following  subelements: 

Line  Charges  -  include  the  cost  of  leased  lines, 
trunks  or  network  service, 

Equipment  -  includes  the  cost  of  modems, 
concentrators,  front-end  processors,  terminals 
equipment  maintenance  service. 

Occupancy  -  The  occupancy,  or  space  cost  element  is 
used  to  identify  the  costs  required  to  house  the  project 
team.  It  is  a  cost  element  that  has  been  occasionally 
overlooked,  since  occupancy  costs  are  frequently  borne 
by  a  service  agency  (e.g.  GSA).  The  occupancy  cost 
element  consists  of  the  following  subelements: 

Facilities  -  include  the  building,  land,  common 
areas,  leasehold  improvements,  and  other  physical 
structures. 

Utility  Services  -  include  electric  power,  gas,  oil, 
coal,  water,  sewage  and  garbage  service, 

-  ■  Office  Equipment  -  includes  the  general  office 
furniture  and  fixtures,  typewriters,  copiers,  plants, 
pictures,  decorating  fees,  etc.. 

Housekeeping  Expenses  -  include  janitorial  supplies 
and  equipment. 
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Security  Expenses  -  include  the  access  cards, 
cameras,  locks,  monitors  and  alarms  required  to 
control  access  to  the  building  or  the  computer 
installation, 

Environmental  Controls  -  include  the  normal 
heating  and  air  conditioning  equipment  expenses  as 
well  as  an  uninterrupted  power  source,  humidifiers, 
dehumidifiers,  water  chillers. 

Other  Occupancy  Expenses  -  include  all  other 
occupancy-related  costs  not  included  above. 

ADP  Supplies  -  In  a  typical  ADP  operation,  ADP  supplies 
can  account  for  a  small,  but  significant  percentage  of 
costs.  For  this  reason,  a  separate  cost  element  is 
assigned  to  distinguish  the  ADP-related  supplies  from  all 
other  supplies. 

Miscellaneous  Expenses  -  Miscellaneous  expense  is  a  cost 
element  that  incorporates  costs  not  specifically  detailed 
by  the  prior  cost  elements.  It  should  include  general 
categories  of  expenses  that  are  not  ADP  related.  The 
characteristics  of  each  project  will  determine  the 
materiality  of  the  subelements  defined  for  this  cost 
element  The  list  of  subelements  that  follows  should  be 
used  as  a  guide  that  can  be  expanded  as  needed  to 
provide  a  consistent  level  of  cost  detail 

Office  Supplies  -  include  general  administrative 
office  supplies  that  are  not  directly  ADP-related. 
These  would  include  pens,  pencils,  copier  paper, 
pads,  folders  and  the  like. 

Telephone  Services  -  include  the  chaises  for  local 
service,  long-distance  and  special  voice 
communication  lines. 

Printing/Duplicating  Expenses  -  include  the  cost  of 
using  off-site  printing  and  duplicating  services. 

Small  Contract  Services  -  include  the  relatively 
small  contract  services  that  cannot  be  defined  in 
terms  of  other  cost  elements,  or  are  too  small  to 
be  of  material  significance.  Major  software 
conversion  contracts  should  be  identified  by  the 
specific  resources  (amount  and  price)  beir^ 
provided  to  allow  a  detailed  identification  of  costs. 
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Overhead  -  includes  indirect  costs  associated  with 
the  performance  of  a  project  that  cannot  be 
defined  in  terms  of  other  cost  elements,  or  are  too 
small  to  be  of  material  significance.  The  use  of 
this  overhead  category  should  be  kept  to  a 
minimum  since  the  objective  of  the  cost  structure 
is  the  identification  of  the  full  cost  detail 

General  and  Administrative  (G&A)  -  similar  to  the 
overhead  category,  G&A  is  common  in  the  federal 
government  as  a  means  of  allocating  indirect  costs 
to  an  operating  unit.  As  with  overhead,  the  use  of 
the  G&A  element  should  be  summarized  and 
applied  only  when  a  cost  detail  is  not  available  or 
the  amount  of  the  cost  is  relatively  insignificant. 

The  cost  element  dimension  detail  provided  in  this  section 
should  be  used  as  a  foundation  for  the  construction  of  a  conversion  cost 
structure  that  is  representative  of  the  software  conversion  effort  and 
reflects  the  full  cost  of  the  project.  The  function  dimension  discussed  in 
the  following  section  serves  as  an  additional  means  of  assurir^  that  the 
full  costs  of  the  software  conversion  are  addressed. 

C.4.2  FUNCTION  DIMENSION 

Functions  are  general  categories  that  may  include  one  or  more 
activities  that  are  performed  during  the  software  conversion  project.  It  is 
important  to  distinguish  between  functions  and  activities.  From  a  project 
management  standpoint,  activities  are  important  for  establishing  project 
controL  Conversion  activities  may  not  require  a  substantial  amount  of 
resources,  for  example,  the  appointment  of  a  project  manner.  From  a 
cost  estimation  standpoint,  however,  conversion  functions  better 
represent  the  conversion  effort.  The  function  dimension  is  included  in  the 
cost  structure  since  it  aids  in  the  identification  of  the  full  cost  of  a 
software  conversion  project  by  identifying  all  significant  functions.  Also, 
the  function  dimension  helps  in  the  cost  estimation  process  by  providing 
cost  categories  that  correspond  to  existing  software  conversion  cost 
estimation  models,  and  are  sufficiently  detailed  to  provide  a  work 
breakdown  structure  with  which  to  develop  costs.  A  consistent  set  of 
software  conversion  functions  can  also  aid  in  the  use  of  historical  costs  to 
estimate  future  software  conversion  costs.  The  following  functions 
illustrated  in  Figure  C-3,  correspond  to  the  conversion  tasks  identified  by 
the  Federal  Conversion  Support  Center  and  include: 

o  Conversion  Management  and  Administration  -  includes 
the  resources  involved  in  managing  and  administering  the 
conversion  effort,  such  as  user  and  upper  management 
liaison,  contract  administration,  and  personnel  activities 
involving  the  project  team. 
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CONVERSION  MANAGEMENT  AND 
ADMINISTRATION 


SYSTEM  AND  PARALLEL  TESTING 


CONVERSION  PLANNING  ANALYSIS 
AND  PREPARATION 

•  PROJECT  PLANNING 

•  STUDY  PREPARATION  AND 
SOFTWARE  INVENTORY 
IDENTIFICATION 

•  POLICY  REVIEW 

•  SOFTWARE  WORK  PACKAGE 
PREPARATION 

•  TEST  DATA  GENERATION 


APPUCATION  PROGRAM  AND  SYSTEM 
SOFTWARE  CONVERSION 


TRAINING 

•  CONVERSION  TOOLS 

•  TARGET  SYSTEM  AND  TARGET 
SOFTWARE 

SOFTWARE  UPGRADE 

•  CONFORMITY  TO  ANSI  STANDARDS 

•  COMPLETE  CURRENT  SYSTEM 
DOCUMENTATION 

•  PURGE  OBSOLETE  SOFTWARE 

•  FUNCTIONAL  SOFTWARE  REDESIGN 


DATA  FILE  AND  DATA  BASE  CONVERSION  GENERAL 


•       FACIUTIES  MAINTENANCE, 
SECURITY  ETC. 

AVERAGE  COMPLEXITY 
TRANSLATIONS 

COMPLEX  TRANSLATIONS 

VERY  COMPLEX  TRANSLATIONS 


TRANSFERS  ONLY 
SIMPLE  TRANSLATIONS 


OPERATION  CONTROL  LANGUAGE 
OPERATING  PROCEDURE  CONVERSION 


REDOCUMENTATION 


SOFTWARE  CONVERSION  FUNCTION  DETAIL 


Figure  C-3 
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Conversion  Planning,  Analysis,  and  Preparation  -includes 
the  preliminary  conversion  activities  such  as: 

Project  planning  and  analysis  at  the  project, 
system  and  task  levels,  and  identification  of  the 
conversion  work  package, 

Study  preparation  and  software  inventory 
identification  including  quantity,  language,  age, 
documentation,  etc.. 

Review  and  implementation  of  conversion  policy, 
procedures  and  documentation  standards, 

Preparation  of  the  software  work  package. 

Test  data  generation  and  validation. 

Application  Program  and  System  Software  Conversion  - 
includes  the  resources  required  for  reprogramming, 
program  logic  modification,  simple  translation  or  other 
methods  of  software  conversion,  including  the  use  of 
conversion  translators  and  aids. 

Data  File  Conversion  -  includes  the  following  types  of 
conversions: 

Transfer  only  -  where  the  source  and  target 
systems  and  environments  are  fully  compatible. 

Simple  translation  -  where  the  conversion  is 
basically  character-to-character,  from  source  to 
target  character  set,  on  a  one-to-one  basis. 

Average  complexity  translation  -  which  involves 
character-to-character,  character- to- word,  or 
word-to-word  conversions  with  the  conversion 
parameters  embedded  in  the  files. 

Complex  translation  -  where  the  conversion  para- 
meters are  external  to  the  files  These  conversions 
usually  require  development  or  modification  of 
several  pieces  of  conversion  software  and  generally 
call  for  multiple  steps, 

Very  complex  translation  -  usually  includes  DBMS 
files  and  may  require  major  development  of  special 
software, 
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Operation  Control  Language  Operating  Procedure 
Conversion  -  includes  the  resources  required  to  convert 
the  operating  procedures  from  one  environment  to 
another,  including  rewriting,  reprogramming,  and  the  use 
of  operation  control  language  translators  and  generators, 

Redocumentation  -  includes  the  resources  used  in 
reviewing  and  analyzing  existing  documentation, 
rewriting,  and  clerical  editing,  proofing,  and  typing  of 
the  new  software  documentation, 

System  and  Parallel  Testing  -  includes  the  resources  used 
in  the  system  test  and  parallel  test  of  the  system  to 
demonstrate  interoperability  between  system  compon- 
ents (programs,  files,  and  job  streams)  and  overall 
correct  execution.  When  the  system  functions  as 
expected,  software  acceptance  testir^  would  commence 
to  achieve  acceptable  comparison  of  outputs  against  the 
current  or  source  system  results, 

Training  -  includes  the  resources  used  in  training  course 
preparation,  delivery  and  participation  for  the  following 
activities: 

Training  which  trains  the  project  team  in  new 
conversion  techniques  or  the  use  of  software 
conversion  tools. 

Training  which  trains  functional  users,  DP  staff, 
project  team  and  other  personnel  in  the  target 
system  environment,  and  target  system  software. 

Software  Upgrade  -  used  to  identify  software  costs 
incurred  during  a  conversion  not  directly  associated  with 
new  hardware.  These  costs  must  be  budgeted  and 
tracked,  but  may  or  may  not  be  included  for  hardware 
evaluation  purposes,  depending  upon  the  regulations 
currently  in  force  Software  upgrade  occurs  whenever 
current  applications  are  changed  to  conform  with 
government  ANSI  standard  language,  documentation  is 
developed  to  provide  a  complete  description  of  the 
current  systems,  obsolete  programs  are  purged,  or  a 
functional  redesign  of  a  program  is  performed. 

General  -  is  designed  as  a  default  category  with  which  to 
identify  functions  not  specifically  addressed  above. 
Examples  of  functions  that  could  be  included  in  this 
category  include  facilities  maintenance,  production 
control,  and  security  functions. 
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C.4.3 


PHASE  DIMENSION 


The  phase  dimension  corresponds  to  the  software  conversion 
phases  described  in  the  body  of  these  guides.  Phase  dimensions  are  useful 
in  large  projects  in  providing  a  logical  and  somewhat  sequential  grouping 
of  conversion  activities  that  provides  better  upper  management  control 
through  the  use  of  milestone  approval  points.  Through  a  standard 
assignment  of  software  conversion  activities  to  phases,  historical  costs 
from  many  projects  may  be  recorded  in  a  consistent  manner  and  used  for 
future  cost  estimates,  and  to  develop  and  validate  cost  estimation  models. 
It  is  important  to  note  that  the  definition  of  phases  will  result  in  some 
overlap  That  is,  as  one  phase  is  being  completed,  activities  in  the  next 
phase  are  already  being  performed.  The  software  conversion  phases 
identified  in  the  cost  structure  include: 

o  Project  Initiation  Phase  -  where  the  decision  is  made  to 
undertake  a  conversion  effort, 

o  Conversion  Requirements  Phase  -  where  the  detailed  in- 
vestigation and  identification  activities  are  performed, 

o  Conversion  Planning  Phase  -  where  the  conversion  plans 
and  schedules  are  developed  in  detail  based  upon  require- 
ments defined  in  the  previous  phase, 

o  Conversion  Preparation  Phase  -  where  the  activities  that 
are  required  to  begin  the  conversion  process  are 
completed, 

o  Conversion  Phase  -  where  the  activities  identified  to 
perform  the  transition  of  software  from  the  source 
environment  to  the  target  environment  is  accomplished, 

o  Post  Conversion  Phase  -  where  the  conversion  team  is 
reassigned  to  normal  duties  and  then  post  conversion 
project  analysis  is  conducted. 

While  costs  may  be  incurred  prior  to  the  appointment  of  a  project 
manager  in  the  project  initiation  phase,  or  after  a  post-conversion 
analysis,  they  are  not  included  as  estimates  in  the  software  conversion 
project  cost.  Activities  in  these  areas  fall  outside  the  perspective  of 
viewing  conversion  as  a  "project."  The  conversion  project  costs,  i.e. 
those  that  are  incurred  from  the  time  a  project  is  started  through 
completion  are  the  most  important.  More  detail  concerning  the  specific 
activities  included  in  each  software  conversion  phase  can  be  found  in  the 
body  of  these  guides.  The  relationship  between  the  cost  element,  function 
and  phase  dimensions  is  depicted  in  Figure  C-4. 
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C.4.4 


TIME  DIMENSION 


The  time  dimension  identifies  the  calendar  period  in  which 
costs  are  expected  to  be  incurred.  The  time  dimension  is  included  in  the 
cost  structure  for  budgetary  purposes  to  assist  in  project  planning  and 
control,  and  to  aid  in  present  value  cost  analysis  for  relatively  long 
software  conversion  efforts.  The  detail  incorporated  in  the  time 
dimension  ^ould  reflect  the  use  of  the  cost  information  by  project 
management  and  the  ability  to  accurately  estimate  costs.  Thus,  during 
project  initiation,  software  conversion  costs  used  for  a  cost-effectiveness 
analysis  may  be  estimated  for  the  next  four  quarters,  and  annually 
thereafter  Prior  to  the  commencement  of  the  conversion  phase, 
however,  costs  may  be  required  to  be  estimated  for  each  month  for 
project  control  purposes  In  general,  software  conversion  costs  should  be 
estimated  at  least  by  fiscal  year  and  for  periods  not  shorter  than  a 
month. 

C.4.5  LOCATION  DIMENSION 

The  location  dimension  identifies  the  geographical  site  where 
a  function  of  the  software  conversion  is  beir^  performed.  It  addresses 
personnel,  equipment  and  occupancy  resources,  the  price  of  which  may 
vary  by  location  Thus,  the  use  of  a  location  dimension  aids  the 
conversion  costing  methodology  by  allowing  the  estimation  and  analysis  of 
geographic  cost  differences  relative  to  the  total  conversion  cost  figure. 
The  location  dimension  should  be  included  with  software  conversions  that 
involve  multiple  sites. 

C.4.6  PRODUCT/SERVICE  DIMENSION 

The  product/service  dimension  is  used  to  allocate  the  cost  of 
the  conversion  to  specific  operational  objectives  performed  by  the 
facility  These  objectives  could  be  stated  as  ADP  services  (e.g. 
timesharing,  batch  processing),  programs  supported  (e.g.  anti-aircraft 
missile,  solar  energy)  or  applications  processed  (e.g.  general  ledger, 
payroll,  disbursements,  personnel).  Where  more  than  one  product 
classification  is  appropriate  different  product  dimensions  may  be 
material  This  dimension  will  allow  the  project  manager  to  estimate  the 
cost  to  convert  each  individual  system  or  conversion  unit. 

C.4.7  ORGANIZATION  DIMENSION 

The  organization  dimension  identifies  the  component,  agency, 
department  or  division  that  performs  functions  of  the  project.  In  this 
respect  it  assists  in  the  identification  of  the  full  cost  of  a  project  by 
providing  a  structure  definition  that  extends  beyond  the  budget  concerns 
of  the  primary  organization.  The  organization  dimension  also  aids  in  the 
identification  of  inter-and  intra-governmental  support  in  performing 
conversion  functions. 
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The  identification  of  the  conversion  cost  structure  is  the  first  step  in  the 
development  of  the  cost  of  a  software  conversion  project.  Through  the 
use  of  cost  structure  dimensions,  the  identification  of  the  full  cost  of  the 
project,  the  estimation  of  the  individual  cost  detail,  and  the  analysis  and 
application  of  the  estimated  costs  can  be  assisted. 

C.5  ESTIMATION  OF  COSTS 

Once  the  cost  structure  has  been  identified  for  the  specific 
conversion  project,  estimates  of  cost  must  be  developed  for  the  structure 
detaiL  This  section  presents  this  cost  estimation  process  in  both  a 
general  and  specific  format. 

It  is  difficult  to  identify  a  single,  universally  acceptable 
approach  to  estimate  conversion  costs  The  estimation  technique  used 
will  vary  with  the  degree  of  accuracy  required,  characteristics  of  the 
software  conversion  project,  and  the  use  of  the  cost  data  during  the 
conversion  phases.  The  basic  steps  required  to  estimate  costs  include  the 
following: 

o  Identify  the  Conversion  Cost  Structure  Detail 
Appropriate  for  the  Project  -  This  is  accomplished  by 
using  the  multidimensional  cost  structure  described  in 
the  previous  section.  The  cost  structure  can  assist  in  the 
cost  estimation  process  by  dividing  the  conversion  cost 
into  manageable  pieces. 

o  Estimate  Resources  -  The  next  step  in  the  cost 
estimation  process  is  to  identify  the  quantity  of 
resources  required  to  perform  a  given  conversion 
function.  The  cost  element  dimension  provides  the  list 
of  resources,  while  the  function  dimension  identifies  the 
workload  requirements.  Since  resources  will  rarely  be 
100%  utilized,  an  adjustment  should  be  included  in  the 
resource  estimate  to  provide  excess  capacity  whether  in 
terms  of  man-hours,  processing  time,  or  space  require- 
ments. 

o  Estimate  Unit  Price  -  The  price  of  a  given  resource  (or 
cost  element)  unit  must  be  estimated  The  price  may  be 
dependent  upon  the  conversion  function  performed  (e.g 
skill  level  required),  location  and  time  period.  Price  can 
be  affected  by  inflation  factors,  government  discounts, 
or  quantity  discounts.  Multiplying  quantity  times  price 
will  give  the  cost  of  a  single  cost  structural  unit. 

The  estimation  process  is  not  static  throughout  the  conversion 
project.  The  use  of  cost  estimation  models  and  techniques  at  the 
beginning  of  the  conversion  project  may  be  sufficient  to  provide  the 
accuracy  for  a  limited  cost-effectiveness  analysis.  Later  in  the  project,  a 
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given  cost  estimation  model  may  not  provide  the  accuracy  necessary  to 
estimate  the  structural  cost  units.  The  degree  of  estimation  will  also 
change  during  the  conversion  project  phases.  For  a  l^rge  conversion 
project,  costs  may  be  adequately  expressed  to  the  nearest  $1,000  during 
the  project  initiation  phase.  Later,  costs  may  be  required  to  the  nearest 
hundred  dollars  The  dimensional  levels  of  detail  that  are  material  can 
also  change  during  the  project.  When  dealing  with  broad  conversion 
strategies  it  may  be  possible  to  estimate  at  a  gross  level  of  detaiL  Later, 
increasingly  finer  levels  of  detail  will  be  defined.  Cost  estimation 
techniques  that  address  a  gross  detail  level  may  not  be  appropriate  to  use 
in  estimating  the  lower  detail  levels  of  the  conversion  cost  structure.  The 
estimation  process  described  in  this  section  must  be  used  with  common 
sense  and  adjusted  to  fit  the  characteristics  of  the  individual  project  and 
its  changing  requirements  for  cost  information  durir^  the  project  phases. 

As  a  basis  for  the  specific  cost  estimation  process,  the 
following  section  presents  a  general  discussion  of  cost  estimation 
techniques  that  may  be  applied. 

C.5.1  ESTIMATION  TECHNIQUES  (GENERAL) 

The  cost  estimation  techniques  can  be  used  to  supply  the  cost 
figures  for  the  cost  data  defined  by  the  conversion  cost  structure.  Cost 
estimation  techniques  may  be  simple,  such  as  using  a  previous  conversion 
project's  supplies  cost  and  adjusting  for  inflation;  or  complex,  as  in  the 
case  of  a  parametric  software  conversion  cost  model  The  following 
general  techniques  may  be  used  to  estimate  costs: 

o  Standards  -  The  use  of  standards  relies  on  estimates  for 
resource  quantities  and  price  that  have  been  systemati- 
cally developed  in  the  past.  These  standards  then 
become  stable  reference  points  from  which  new  tasks 
can  be  calibrated.  Due  to  rapidly  changing  ADP 
technology,  past  performance  standards,  such  as  a 
standard  for  conversion  productivity  (e.g.,  number  of 
lines  converted  per  workday),  should  be  examined  before 
they  are  applied  to  estimate  resource  requirements  for 
current  systems. 

o  Modeling  -  Modeling  techniques  attempt  to  predict  cost 
or  resource  requirements  for  the  proposed  system 
without  the  use  of  a  full-scale  development  and  trial 
period.  Modelir^  techniques,  such  as  the  Federal 
Conversion  Support  Center  cost  estimation  model,  are 
useful  durir^  the  early  phases  of  the  conversion  project 
planning  process  to  provide  an  estimation  of  cost.  As 
such,  they  can  be  useful  during  preliminary  cost- 
effectiveness  analyses  to  determine  the  cost  impact  of 
proposed  alternatives. 
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o  Historical  Cost  Application  -  The  use  of  historical  costs 
is  generally  limited  to  the  refinement  of  future 
conversion  phase  cost  estimates  based  on  cost  data 
collected  for  recently-completed  conversion  phas-^  If 
historical  cost  records  have  been  maintained,  for 
example,  the  cost  of  regularly  scheduled  management 
review  meetings,  these  costs  could  provide  the  basis  for 
developing  accurate  cost  estimates  for  use  throughout 
the  project. 

C.5.2  SOFTWARE  CONVERSION  COST  ESTIMATION  MODELS 

The  difficulty  in  accurately  estimating  the  cost  of  software 
conversion  has  led  to  the  development  of  cost  estimation  models  to 
provide  a  simple  solution  to  the  estimation  problem.  While  a  complete 
description  of  the  use  of  models  is  beyond  the  scope  of  this  appendix,  the 
models  summarized  below  serve  as  an  overview  to  provide  guidance  as  to 
the  models  currently  available  at  the  time  of  the  publication  of  this 
guides  that  have  significant  application  to  federal  conversion  and  the 
strength  and  applicability  of  each.  The  use  of  software  conversion 
estimation  models  siiould  prove  beneficial  in  the  early  phases  of  the 
conversion  where  only  gross  detail  is  required  and  accuracy  is  not  criticaL 
These  models  should  be  used  only  with  a  thorough  understandir^  of  the 
basis  upon  which  the  model  was  developed,  the  cost  elements,  functions  or 
phases  covered  by  the  model,  and  the  projects  in  which  the  model  output 
has  been  validated. 

o  Federal  Conversion  Support  Center  Model  -  The  Federal 
Conversion  Support  Center  ''FCSC)  model  was  developed 
in  1980.  The  FCSC  model  is  primarily  a  parametric 
software  conversion  cost  estimation  model  The  model 
features  an  excellent  breakdown  by  functions  which 
facilitates  cost  estimation.  The  model  includes  most 
cost  elements,  and  it  explicitly  states  those  elements  it 
does  not  include.  The  model  is  sufficiently  flexible  to 
handle  most  complex  conversions,  and  covers  essentially 
all  phases  of  a  conversion  effort.  While  the  FCSC  model 
has  not  been  extensively  validated  at  the  time  this  guide 
was  prepared,  it  appears  to  be  the  best  software  cost 
estimation  model  available  from  public  sources. 

The  FCSC  model  has  several  distinct  advantages. 
Although  incomplete,  this  model  does  have  a 
comprehensive  treatment  of  costs.  The  FCSC 
model  was  designed  to  be  applicable  to  a  wide 
range  of  conversions  and  there  are  plans  for  future 
enhancements.  On  the  other  hand,  the  coefficients 
and  values  assigned  for  DBMS  and  other  complex 
conversions  are  untested.    Subjective  assessments 
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are  required  in  certain  cost  areas  and  it  does  not 
recognize  effects  on  conversion  costs  of  over- 
assignment  or  under-assignment  of  personnel.  The 
applicability  of  the  model  appears  to  be  universal. 

o  Project  Management  Control  System  II  -  Project 
Management  Control  System  II  (PMCS),  which  is  also 
known  as  the  Navy  Model,  was  developed  by  Naval  Data 
Automation  Command  (NAVDAC).  It  is  a  parametric 
software  conversion  cost  estimation  model  which  is 
based  on  batch-to-batch  COBOL  conversions  similar  to 
those  performed  in  the  1970's  at  NAVDACs  (then  Data 
Processing  Service  Centers).  PMCS  is  based  on  four 
similar  conversions  encompassing  over  100  man-years  of 
work.  These  conversions  were  primarily  business 
oriented,  batch,  COBOL  systems.  PMCS  is  primarily 
oriented  towards  professional  staff-days,  not  towards 
dollars.  It  excludes  discussion  of  costs  such  as  admini- 
stration, data  entry,  computer  operators,  and  supervisory 
time  which  can  be  significant  in  government  ADP  oper- 
ations, but  not  the  associated  costs.  PMCS  includes  a 
management  reporting  system  and  automated  manpower 
estimating  aids.  Reports  produced  are,  however, 
primarily  a  recompilation  of  data  provided  by  the  user. 

PMCS  is  relatively  easy  to  use,  validate,  and  refine,  and 
is  apparently  not  limited  by  hardware  (assumption  of  the 
model's  developers).  It  contains  excellent  coverage  of 
the  phases  of  a  conversion  effort.  PMCS  is  based  on 
data  of  questionable  statistical  value,  because  some  of 
the  original  data  was  discarded.  Furthermore,  the  model 
is  based  on  major  conversion  efforts  and  thus  may  not  be 
clearly  applicable  to  small  and  medium-sized  conversion 
efforts.  PMCS  can  be  used  for  batch-to-batch,  business- 
oriented,  COBOL  to  COBOL,  flat-file  to  flat-file 
conversions. 

It  is  not  always  possible  to  draw  a  distinction  among  the  cost 
estimation  techniques  described  above.  They  do  have  one  common  factor 
in  their  use  of  historical  information  to  predict  future  events.  It  should 
be  evident  that  if  software  conversion  cost  information  can  be  recorded  in 
a  detailed  and  consistent  manner,  for  historical  purposes,  the  accuracy  of 
the  cost  estimation  process,  in  general,  can  improve. 

C.6  ANALYSIS  OF  THE  COST  DATA 

Just  as  estimation  techniques  vary  according  to  the  require- 
ments of  the  project  for  which  costs  are  estimated,  the  analysis 
techniques  that  are  appropriate  for  each  situation  depend  upon  the 
characteristics  of  the  project  and  of  the  decision  being  addressed.  This 
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section  describes  several  analysis  techniques  that  are  applicable  to  a  wide 
range  of  situations.  The  applicability  of  each  technique  is  dependent  upon 
factors  such  as  the  phase,  function  and  alternatives  analyzed  for  a 
particular  project.  It  is  important  to  understand  the  value  and  the 
limitations  for  each  technique  before  attempting  to  use  them  for  making 
decisions. 

Certain  cost  concepts  and  analysis  techniques  discussed  in  this 
section  must  be  performed  to  satisfy  the  requirements  of  specific 
directives.  Where  applicable,  the  discussion  of  cost  analysis  includes  a 
description  of  how  the  costs  are  related  to  relevant  directives. 

C.6.1         COST  CONCEPTS  DEFINITION 

The  framework  and  procedures  that  are  presented  in  this 
appendix  for  developing  costs  are  based  upon  the  concept  of  full  costing. 
That  is,  by  defining  the  full  costs  of  a  project  in  a  detailed  manner  (i.e., 
multidimensional  structure)  it  will  be  possible  to  derive  cost 
classifications  from  a  single  cost  base.  This  is  important  in  responding  to 
directives,  since  the  format  and  classification  of  this  cost  information 
may  vary.  The  cost  concepts  addressed  below  have  been  the  source  of 
confusion  in  the  application  of  cost  information.  While  each  concept  is 
briefly  discussed,  a  full  definition  can  best  be  obtained  from  financial  and 
accounting  reference  material. 

o  Direct/Indirect  Costs  -  Costs  may  be  classified  as  either 
direct  or  indirect.  The  purpose  of  identifying  costs  as 
direct  or  indirect  is  to  assign  all  costs  as  precisely  as 
possible  to  the  specific  product,  service,  customer  or 
other  cost  objective  they  support.  Some  costs  are  easily 
assigned  directly  to  a  product  or  service.  For  example, 
the  cost  of  programmers  that  are  dedicated  to  convert  a 
specific  application  is  a  direct  cost  of  that  application. 
The  most  common  direct  costs  are  for  labor  and  supplies. 
Other  possible  direct  costs  include  travel,  purchased 
services  and  service  center  charges  for  items  such  as 
printing. 

Indirect  costs  are  costs  that  cannot  be  directly  related 
to  a  product  or  service,  or  costs  that  are  insignificant  or 
difficult  to  measure.  Examples  of  items  that  are  often 
classified  as  indirect  costs  are  low  cost  supplies  such  as 
paper  clips;  the  labor  costs  of  receiving,  storing  and 
distributing  materials  and  supplies;  depreciation  of 
buildings  and  general  purpose  equipment;  utilities;  and 
general  and  administrative  expense  for  financial 
management  and  other  services  that  benefit  the  entire 
organization.  Indirect  costs  may  still  be  assigned  to 
specific  cost  objectives  but  the  assignment  is  through  an 
allocation  process.  The  total  indirect  cost  is  spread 
among  all  cost  objectives  according  to  criteria  such  as 
number  of  people  or  total  budget  dollars. 
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Because  separating  full  costs  into  direct  and  indirect 
costs  permits  a  careful  assignment  of  costs  to  specific 
products  or  services,  it  is  useful  for  conversion  budgeting 
and  project  monitoring  applications.  A  clear  separation 
of  costs  assists  managers  who  are  responsible  for 
controlling  resources  and  costs  that  are  associated  with 
projects  under  their  supervision.  Awareness  of  the  true 
cost  of  providing  or  receiving  services  permits  managers 
to  make  informed  decisions. 

o  Constant/Current  Dollars  -  The  purchasing  power  of  a 
dollar  during  one  year  is  not  necessarily  the  same  as  the 
purchasing  power  of  that  dollar  during  some  future  year. 
Inflation  means  that  more  dollars  will  be  needed  in  the 
future  to  purchase  the  same  goods  that  are  purchased 
with  less  dollars  today.  The  term  "constant  dollars" 
should  be  equated  to  "constant  purchasing  power,"  that 
is,  the  price  of  a  resource  in  terms  of  the  purchasing 
power  of  a  dollar  in  some  base  year.  Current  dollars 
represent  the  actual  cost  outlays  in  the  year  they  are 
expensed,  and  show  the  effect  of  inflation  on  the 
constant  dollar  value. 

Since  both  constant  and  current  dollar  estimates  may  be 
required  during  the  project  (e.g.,  constant  dollars  for 
economic  analyses,  current  dollars  for  budgetary 
submissions),  the  software  conversion  cost  estimates 
should  be  developed  in  such  a  way  as  to  support  both 
requirements.  This  is  accomplished  by  estimating 
software  conversion  costs  using  constant  (base  year) 
dollars.  By  applying  inflation  factors  to  these  estimates, 
current  dollar  figures  can  they  be  determined  for  each 
future  year. 

o  Inflation  -  Inflation  is  the  rise  in  the  general  level  of 
prices  over  time.  Inflation  complicates  financial 
planning  and  cost  analysis  because  it  creates  uncertainty 
about  future  prices.  Current  and  past  rates  of  inflation 
may  be  measured  by  means  of  price  indexes,  which  are 
percentage  comparisons  of  the  prices  of  selected 
commodities  and  services  between  two  periods  of  time. 
Future  rates  of  inflation  can  only  be  estimated.  Once 
the  future  inflation  rate  is  estimated  for  the  years  of  a 
conversion  project's  life,  the  rate  is  applied  to  all  future 
costs  to  adjust  those  costs  for  projected  price  increases. 
Because  inflation  affects  the  prices  of  goods  and 
services  to  be  acquired  in  the  future,  it  is  an  important 
consideration  of  full  costing  during  any  planning  or 
estimating  for  items  that  are  subject  to  price  changes. 
Labor,  supplies  and  utilities  are  examples  of  items  that 


169 


may  be  affected  by  inflation.  The  total  costs  estimated 
for  each  year  in  the  conversion  project's  life  are  adjusted 
by  applying  an  annual  inflation  factor  to  each  total. 
Software  conversion  cost  estimates  should  be  able  to 
reflect  costs  in  actual  dollar  expenditures  expected  in 
each  year  of  the  project  for  budgetary  purposes. 
Anticipated  variations  in  the  inflation  rate  should  be 
addressed  through  sensitivity  analysis. 

o  Wash  Costs  -  The  cost  of  some  items  may  be  the  same 
regardless  of  which  of  two  or  more  alternative  courses 
of  action  are  selected.  Although  the  amount  of  the  cost 
may  be  important,  it  will  not  affect  the  outcome  of  a 
cost  comparison  among  the  alternatives.  Such  costs  are 
referred  to  as  wash  costs.  For  example,  if  two  options 
are  for  the  government  to  purchase  and  operate  certain 
equipment  or  to  purchase  the  equipment  and  hire  a 
contractor  to  operate  it,  the  purchase  cost  of  the 
equipment  is  a  wash  cost.  It  may  be  a  major  part  of  the 
total  project  cost  but  the  cost  is  the  same  for  the  two 
alternatives  and  will,  therefore,  not  contribute  more  to 
the  total  cost  of  one  alternative  than  the  other. 

Under  a  concept  of  full  costing,  all  costs  should  be 
included  whether  a  wash  cost  or  not.  This  is  because  a 
total  cost  is  important  for  budgeting  decisions.  Also,  it 
is  difficult  to  correctly  identify  a  wash  cost,  since  cost 
components  may  vary  with  the  alternative  selected.  For 
example,  the  cost  of  management  is  often  considered  a 
wash  cost;  however,  a  software  conversion  in  a  distri- 
buted processing  environment  may  require  more  task 
managers  and  higher  travel  and  administrative  costs  than 
a  software  conversion  in  a  centralized  processing 
environment.  Another  reason  for  including  wash  costs  in 
the  conversion  costing  methodology  is  that  the  scope  of 
the  project  may  change  during  conversion  planning 
preparation.  Costs  which  were  correctly  assumed  to  be 
a  wash,  now  may  have  a  cost  impact  on  the  project 
decisions.  By  addressing  the  full  cost  of  a  project,  all 
cost  areas  would  have  been  included,  whether  a  wash 
cost  or  not. 

C.6.2  ANALYSIS  TECHNIQUES 

Cost  analysis  techniques  are  methods  of  using  previously- 
defined  and  estimated  cost  data  to  make  management  decisions.  The 
nature  of  the  decision  determines  the  techniques  that  are  most 
appropriate  for  each  situation.  The  following  are  examples  of  analysis 
techniques  that  are  valuable  for  management  decisions. 
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o  Present  Value  Analysis  -  Present  value  analysis  is  used  to 
reflect  the  diminishing  value  of  money  with  time. 
Present  value  analysis  equates  future  costs  to  their 
present  worth.  Its  primary  value  is  in  the  assessment  of 
alternatives  that  have  different  cash  flows  and  different 
durations. 

o  Sensitivity  Analysis  -  Throughout  the  costing  process, 
various  assumptions  are  made  concerning  the  cost  data 
used.  These  assumptions  include  inflation  factors,  cost 
estimation,  workload,  etc.  As  part  of  the  cost  analysis 
process,  these  assumptions  should  be  evaluated  to 
determine  if  changes  in  any  one  assumption  will  change 
the  outcome  of  the  analysis. 

o  Break-Even  Analysis  -  Break-even  analysis  is  used  to 
study  cost  relationship  between  alternatives. 

o  Ratio  Analysis  -  Ratio  analysis  is  a  cost  comparative 
process  which  may  be  used  to  compare  cost  data  within 
an  alternative,  among  alternatives  or  with  standard  cost 
data. 

o  Risk  Analysis  -  Risk  analysis  is  a  technique  that  uses 
probabilities  to  assess  the  potential  for  alternative 
outcomes.  By  assigning  probabilities  to  each  alternative 
and  multiplying  by  the  expected  cost  or  outcome  value 
of  that  alternative,  a  total,  expected  value  can  be 
determined.  In  a  software  conversion  project  this 
technique  is  important  in  contingency  planning  to 
develop  a  plan  that  assesses  potentially  harmful  events 
in  a  cost-effective  manner. 

These  techniques  are  intended  only  as  examples  of  the  analysis 
methods  that  are  available  for  use  during  the  project.  The  use  of  these 
techniques,  including  their  strengths,  weaknesses  and  applicability  to 
project  decisions  can  be  obtained  from  a  review  of  financial  reference 
material  It  is  important  to  remember,  however,  that  the  use  of  various 
techniques  may  yield  conflicting  results.  It  is  improper  to  adopt  a  single 
analysis  method  for  use  in  all  applications.  The  analysis  methods  must  be 
applied  judiciously,  with  a  knowledge  of  each  method's  limitations. 

C.7  APPLICATION  OF  THE  COST  DATA 

The  end  objective  of  the  conversion  costing  methodology  is 
support  of  project  management  decisions.  As  illustrated  in  Figure  C-1, 
the  application  of  software  conversion  cost  information  is  directly  related 
to  the  manner  in  which  costs  have  been  defined  using  a  dimensional  cost 
structure.  These  dimensions  allow  the  application  of  a  single  cost  basis  to 
a  variety  of  project  decisions  and  activities.     In  this  section  the 
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application  of  costs  to  specific  conversion  project  decisions  and  activities 
is  summarized  for  each  phase  of  the  conversion.  While  some  cost  impact 
may  be  shown  for  every  software  conversion  activity,  this  section  is 
designed  to  highlight  those  tasks  which  are  most  dependent  upon  the 
costing  information.  An  overview  of  economic  considerations  is  given  in 
Figure  C-5  and  summarizes  the  cost  detail  contained  in  the  body  of  the 
guides. 

C.7.1  PROJECT  INITIATION  PHASE 

Project  initiation  is  the  phase  in  which  the  requirement  for  a 
software  conversion  is  determined.  The  major  product  of  this  phase  is  a 
preliminary  feasibility  study  that  includes  the  cost  estimates  of 
conversion  alternatives,  a  comparison  and  analysis  of  these  alternatives 
based  on  cost  and  technical  factors,  and  a  recommendation  of  a  proposed 
alternative.  Accompanying  this  recommendation  should  be  preliminary 
project  plans  that  will  accomplish  the  alternative  courses  of  action.  Cost 
activities  during  this  phase  include: 

o  Analyze  the  Project  Characteristics  and  Develop  the 
Unique  Project  Cost  Structure  -  It  is  critical  to  develop 
the  specific  cost  structure  which  is  material  to  the 
project  under  investigation.  This  will  require  analysis  of 
the  basic  characteristics  and  goals  of  the  conversion 
project,  and  development  of  a  specific  cost  structure 
which  will  form  the  framework  for  future  cost 
estimates,  cost  evaluation  criteria,  and  cost  tracking. 
This  is  a  major  activity  which  will  require  careful 
planning  to  assure  that  the  correct  structure  has  been 
developed  which  will  allow  continuous  use  throughout  the 
software  conversion  effort. 

o  Establish  a  Preliminary  Conversion  Project  Budget  -  The 
cost  structure  should  be  used  for  budget  preparation  by 
identifying  the  estimated  project  costs  for  the  following 
phases  in  terms  of  various  costs  elements  and  functions. 
Also,  the  scheduling  of  these  expenses  should  be 
established  by  assessing  the  priority  (cost-effectiveness) 
of  the  project  relative  to  other  projects  under  develop- 
ment. 

o  Estimate  Project  Resources  -  The  project  budget  esti- 
mate and  schedule  can  be  matched  to  determine  the 
availability  and  utilization  of  personnel  skill  categories 
to  be  used.  Adjustments  in  personnel  strength  can  be 
made  to  keep  the  project  within  budget  and  schedule,  or 
to  request  additional  funds. 

Approval  of  the  preliminary  feasibility  study  signifies  the  completion  of 
this  phase. 
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C.7.2  CONVERSION  REQUIREMENTS  PHASE 


During  the  conversion  requirements  phase,  the  conversion 
process  is  analyzed  and  methods  and  techniques  are  selected  to 
accomplish  the  effort.  The  culmination  of  this  phase  is  a  software 
conversion  study  that  includes  an  assessment  of  the  current  software 
environment,  a  program  inventory,  and  evaluation  of  contractor's 
assistance  and  a  recommendation  as  to  the  use  of  conversion  tools.  A 
specific  costing  activity  during  this  phase  is: 

o  Project  Planning  and  Staffing  -  Conversion  cost 
information  can  be  used  to  assist  in  project  personnel 
planning  by  determining  the  best  mix  of  project 
personnel  and  determining  the  most  cost-effective 
project  strategy  to  follow.  Cost  trade  of fs  between  skill 
levels,  person-hours  required,  and  personnel  expenses  can 
be  evaluated  for  each  function  during  the  project.  While 
this  impact  on  costs  is  important,  it  should  be  evaluated 
against  management  considerations  such  as  expected 
turnover,  skills  back-up,  critical  staffing  positions, 
employee  development  and  the  like.  Furthermore,  cost 
estimates  can  be  used  to  assist  in  evaluating  alternative 
project  execution  strategies  such  as  length  of  phases,  use 
of  contractors,  and  use  of  software  conversion  tools. 
For  each  project  management  alternative  considered,  a 
cost  estimate  should  be  developed  to  assist  in  evaluating 
the  impact  of  that  approach.  The  final  project  manage- 
ment approach  selected  should  be  based  upon  the  lowest 
total  overall  cost  to  the  organization,  given  the 
constraints  of  the  organization,  and  the  potential  for 
satisfying  the  mission  needs. 

Approval  of  software  conversion  study  marks  the  end  of  this  phase  and 
provides  information  that  feeds  the  conversion  planning  phase. 

C.7.3  CONVERSION  PLANNING  PHASE 

The  conversion  planning  phase  is  used  to  develop  the  detailed 
task  schedules  and  resource  requirements  needed  to  accomplish  the 
conversion.  At  the  completion  of  these  activities  a  formal  conversion 
plan  is  submitted  to  upper  management  for  approval  to  continue  with  the 
project.  This  formal  conversion  plan  should  include  cost-related 
considerations  such  as  a  summary  of  the  conversion  budget,  a  description 
of  the  proposed  cost-tracking  mechanism,  and  analysis  of  the  cost- 
effectiveness  of  proposed  conversion  aids,  and  a  justification  for  the  use 
of  contract  personnel.  Specific  costing  activities  during  this  phase 
include: 

o  Prepare  Action  Plans  -  Cost  information  can  be  used  in 
project  planning  and  budgeting  to  establish  a  project  task 
schedule  (e.g.,  PERT-COST  and  PERT-TIME)  that  allows 
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for  the  development  of  the  project  in  a  cost-effective 
manner.  Important  considerations  at  this  time  should  be 
the  estimated  deployment  date  relative  to  the  expected 
operational  benefit.  The  project  duration  reduction  may 
increase  costs  as  more  overtime  or  contract  employees 
are  used.  This  increase  in  cost,  however,  may  be 
justified  if  the  project  can  become  operational  sooner, 
thereby  decreasing  operational  costs.  The  cost  structure 
provides  the  cost  detail  for  project  functions  to  allow  for 
this  evaluation. 

Refine  Budget  -  The  budget  application  of  cost 
information  will  aid  in  identifying  the  costs  for  the 
current  phase,  updating  project  costs  for  subsequent 
phases,  and  submittir^  the  budget  for  the  following 
year's  effort. 

Formalize  Conversion  Approach  -  This  activity  is  the 
further  refinement  of  the  conversion  plans  developed  in 
the  previous  phase.  At  this  point,  software  conversion 
cost  estimation  models  should  be  compared  against  a 
task-by-task  conversion  plan  to  determine  the  adequacy 
of  resources  (quantity  and  skills)  to  complete  the 
conversion  within  a  suitable  time-frame.  At  this  time, 
the  program  manager  should  examine  the  alternative 
approaches  which  are  available  to  convert  to  the  new 
system.  These  approaches  may  include  complete 
redesign  of  the  system,  line-by-line  translation,  etc.  The 
program  manager  will  need  to  evaluate  the  most  cost- 
effective  conversion  alternative  based  upon  factors  such 
as  the  age  of  the  existing  software  (if  appropriate),  the 
remaining  life  of  the  system,  and  whether  it  currently 
satisfies  user's  requirements.  Furthermore,  the  cost 
impact  of  the  use  of  outside  conversion  services, 
personnel  or  tools  should  be  evaluated  using  the  cost 
information. 

Develop  RFP  and  Evaluation  Criteria  -  If  external 
support  is  to  be  acquired,  the  conversion  costing 
methodology  can  be  used  to  estimate  costs,  identify 
critical  cost  areas,  and  provide  a  cost  evaluation 
criterion  that  considers  the  impact  in  all  relevant  cost 
areas  (price  and  other  cost  factors).  Vendors  should  be 
required  to  submit  cost  data  in  a  format  that  can  be 
included  in  the  project's  cost  structure.  The  conversion 
costing  structure  should  then  be  used  to  evaluate  vendors 
based  on  total  project  costs  that  incorporate  both  direct 
vendor  charges  and  other  agency  project  costs  associated 
with  using  that  vendor.  This  will  require  that  the  cost 
evaluation  criteria  used  in  the  RFP  be  well  documented 
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to  allow  evaluation  of  proposals  based  on  lowest  project 
cost.  Technical  considerations,  such  as  quality,  can  be 
more  easily  related  to  costs  through  the  use  of  a  total 
conversion  costing  methodology.  There  are  certain 
service  acquisition  guidelines  (FPMR,  FPR,  etc.)  which 
address  the  cost  elements  or  functions  which  are 
allowable  in  making  acquisition  decisions.  Since  these 
may  be  open  to  interpretation,  it  is  recommended  that 
oversight  organizations  be  contacted  to  approve  the  cost 
elements  included  in  acquisition  evaluation  criteria. 

Approval  of  the  conversion  plan  identifies  the  completion  of  the 
conversion  planning  phase. 

C.7.4  CONVERSION  PREPARATION  PHASE 

Durir^  this  phase,  the  conversion  manager  accomplishes  the 
activities  required  to  assemble  the  personnel  and  acquire  the  facilities 
and  conversion  tools  needed  durir^  the  conversion  effort.  Costing 
activities  during  this  phase  include: 

o  Vendor  Evaluation  and  Selection  -  Vendor  selection 
should  be  based  on  technical  and  cost  considerations  that 
account  for  the  impact  of  a  particular  vendor's  price  and 
other  cost  factors  on  the  total  cost  of  the  project.  A 
detailed  cost  structure  would  enable  the  conversion 
costing  methodology  to  provide  detailed  resource  cost 
information  for  each  vendor  to  assist  in  the  validation  of 
cost  proposal  and  to  assure  an  adequate  quantity  of 
resources  have  been  proposed.  For  example,  if  support 
staff  is  included  in  the  proposal,  a  detailed  cost 
structure  would  identify  the  level  of  skills,  person  hours, 
and  salary  proposed  by  each  vendor.  In  this  way, 
significant  deviations  between  vendors  may  be 
addressed.  Finally,  the  conversion  costing  methodology 
can  be  used,  through  sensitivity  analysis,  to  identify  the 
cost  areas  most  critical  in  the  vendor's  proposal 
evaluation  and  selection.  These  areas  could  then  provide 
a  basis  for  incentive  clauses  in  the  acquisition  contracts. 

o  Establish  Deployment  and  Delivery  Schedules  -  The 
timing  of  the  deployment  of  the  converted  software  and 
delivery  of  the  proposed  resources  affect  software 
conversion.  There  will  exist  various  approaches  and 
possible  timetables  for  accomplishing  deployment  and 
installation.  Each  schedule  may  have  cost  impacts  in 
terms  of  the  potential  net  benefits  derived  from  the 
project.  The  cost  trade  off  objective  involved  in  this 
scheduling  effort  should  be  the  lowest  total  cost  of  the 
project. 
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o  Develop  Plans  and  Budgets  -  Through  the  use  of 
historical  project  costs  contained  in  the  conversion 
costing  methodology,  the  project  budget,  task  schedule 
and  resource  assignments  can  be  developed  for  the 
conversion  phase.  Cost  considerations  such  as  the  use  of 
overtime  or  contract  personnel,  short-term  rental  of 
additional  equipment  and  space,  and  the  impact  of 
disrupted  agency  workload  ^ould  be  addressed. 

When  preparations  are  complete  the  conversion  phase  begins. 

C.7.5  CONVERSION  PHASE 

During  this  phase,  the  actual  conversion  of  software  from  the 
source  to  the  target  environment  is  accomplished  This  phase  will 
contribute  to  a  significant  amount  of  the  total  conversion  cost  but  will 
have  relatively  few  requirements  for  cost  information  other  than  the 
following  activity: 

o  Evaluate  Conversion  Effort  Against  Conversion  Plans  - 
The  conversion  costing  methodology  can  provide  a 
detailed  cost  structure  with  which  to  accumulate  actual 
cost  data  that  can  be  used  to  compare  actual  cost 
performance  data  with  historical  estimates.  In  this  way 
differences  can  be  easily  identified  for  further  analysis, 
and  the  full  cost  impact  on  the  project  can  be  evaluated. 
This  will  require  that  the  acceptance  cost  data  be 
recorded  consistent  with  the  cost  structure. 

Acceptance  of  the  final  converted  system,  fully  documented  and  tested, 
marks  the  end  of  the  conversion  phase. 

C.7.6  POST-CONVERSION  PHASE 

The  post-conversion  phase  is  des^ned  to  provide  an 
assessment  of  the  completed  project  and  prepare  the  organization  for 
future  software  conversions.  As  such  it  is  a  continuous  process  with  no 
clearly  defined  end  point  The  use  of  software  conversion  costs  during 
this  phase  consists  of  the  following  activities: 

o  Post-Conversion  Analysis  and  Assessment  -  The  analysis 
of  project  performance  should  be  performed  as  part  of  a 
post-implementation  audit.  The  conversion  costing 
methodology  can  assist  in  this  validation  by  providing  an 
historical  cost  basis  and  audit  trail  against  which  actual 
performance  data  can  be  measured.  If  actual  system 
performance  significantly  deviates  from  planned  system 
performance,  the  conversion  costir^  methodology  can 
help  identify  the  cost  areas  and  reasons  for  the 
differences.  The  function  and  product  dimension  of  the 
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cost  structure  can  assist  in  projecting  user's  charges  and 
evaluating  the  cost-effectiveness  of  changing  user's 
requirements,  and  their  impact  on  these  user  charges. 

Satisfy  A-12  Requirements  -  0MB  Circular  A-12  requires 
development  of  annual  agency  long-term  plans  to  support 
budget  submissions.  Such  plans  project  agency 
requirements  for  five  years  or  longer.  Conversion 
costing  methodology  is  directly  applicable  to  conversions 
considered  in  these  plans. 

Agency  Budget  Submissions  -  Similar  to  A-12 
requirements,  conversion  costing  methodology  supports 
agency  budget  actions. 

Satisfy  A-'^S  Requirements  -  0MB  Circular  A-76  requires 
regular  assessments  of  £^ency  commercial-industrial 
type  activities  to  weigh  the  benefits  of  continual 
government  operation  against  contractor  operation. 
ADP  services  fall  under  the  provision  of  A-"6. 
Conversion  costing  methodology  can  be  usefully  applied 
to  any  agency  A-76  studies  conducted  during  the  post- 
conversion  phase. 

Satisfy  A-109  Requirements  -  0MB  Circular  A-109 
requires  cost  analyses  to  be  performed  for  major  system 
acquisitions.  Large  scale  agency  hardware  replacements 
are  frequently  considered  to  fall  under  the  provisions  of 
0MB  Circular  A-109.  The  conversion  costing 
methodology  will  directly  support  A-109  conversion  cost 
assessments. 

Satisfy  A-121-Requirements  -  0MB  Circular  A-121 
prescribes  the  initiation  of  business-like  procedures  that 
require  agencies  to  account  for  the  full  cost  of  operating 
a  DP  facility,  to  allocate  all  costs  to  users  according  to 
services  they  receive,  and  to  share  excess  DP  capacity. 
These  costs,  when  developed,  rarely  include  the  costs  of 
conversion  and  lead  to  under  resourcing  conversion 
staffs.  By  maintaining  the  conversion  costir^ 
methodology  and  accounting  for  cost  incurred  according 
to  its  structure  throughout  the  life  of  the  project,  the 
cost  information  used  in  satisfying  A-121  should  be 
available.  The  conversion  costing  methodology  provides 
the  structure,  through  the  use  of  organization  and 
product  dimensions,  for  allocation  of  conversion  costs  to 
users  according  to  service  provided. 


178 


APPENDIX  D 
CASE  STUDIES 
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SUMMARY 


This  appendix  contains  eleven  ease  studies  of  software 
conversion  projects  at  Federal  agencies.  Some  projects  had  been 
completed;-  others  were  in  planning  and  execution  stages  when  these 
studies  were  developed  They  provide  additional  insight  into  software 
conversion  problems  and  illustrate  that  management  attention  is 
necessary  to  improve  conversion  efficiencies.  Readers  of  this  guide  may 
find  situations  analogous  to  their  agency  conversion  environments  and 
take  action  to  preclude  repeating  mistakes  made  by  others. 
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AGENCY  1  EXPERIENCE 

BACKGROUND 

The  organization  discussed  is  an  element  of  a  federal  agency 
and  is  a  user  of  the  agency's  computer  system  (approximately  10%  of 
machine  time).  The  organization  had  an  in-house  staff  of  programmers 
and  analysts  to  develop  and  maintain  its  automated  information  systems. 
The  ADP  department  of  the  agency  acted  as  a  service  bureau  to  other 
departments  and  organizations  in  the  agency. 

Because  of  saturation,  the  agency  decided  to  upgrade  its  IBM 
360/65.  A  competitive  procurement  resulted  in  selection  and  installation 
of  a  UNIVAC  1100/43  system.  Because  of  the  results  of  the  competitive 
procurement,  the  organization,  as  well  as  other  users  of  the  hardware 
executed  a  non-code  compatible  software  conversion. 

This  conversion  experience  illustrates  problems  associated 
with  such  a  conversion  as  weU  as  problems  facing  users  of  a  large, 
"service-bureau"  type  of  operation. 

THE  CONVERSION 

Application  programs  on  the  IBM  360/65  were  written  in 
COBOL,  PLl,  FORTRAN,  Assembly  Language  and  RPG.  Approximately 
75  percent  were  written  in  the  latter  lar^uage.  Little,  if  any,  software 
documentation  existed  for  the  IBM  applications.  There  were  many  user 
enhancements  which  were  pending  but  not  incorporated  in  the  old 
software  because  machine  saturation  precluded  development  and  test 
time. 

The  decision  to  upgrade  was  made  in  the  1975-1976  time 
frame.  Conversion  planning  started  in  mid-1977  and  the  target  hardware 
was  installed  in  mid  1978. 

Soon  after  selection,  UNIVAC  made  computer  time  available 
through  Remote  Job  Entry  (RJE)  stations.  This  service  was  convenient, 
and  facilitated  the  conversion.  However,  this  service  was  not  used  to 
(^timum  advantage  in  accompli^ing  early  training  and  software 
conversion.  The  failure  to  use  this  resource  to  fuU  advantage  ultimately 
contributed  to  conversion  slippage. 

The  organization  decided  to  convert  and  redes^n  applications 
concurrently  into  a  DataBase  Management  Systems  (DBMS),  System  2000. 
It  was  anticipated  that  aU  applications  could  be  converted  before  the  IBM 
system  was  released.  However,  this  did  not  occur.  Although  the  IBM 
hardware  had  been  removed  in  late  1980,  as  of  January  1981  the 
conversion  was  still  in  progress  and  expected  to  take  an  additional  year. 
The  loss  of  this  hardware  resulted  in  a  line  for  line  conversion  of  some  old 


181 


applications  without  redesign  and  without  parallel  testing.  Nine  major 
DBMS  applications  were  active  with  approximately  400,000,  40-60 
character  records.  Four  similar  applications  remained  to  be  built. 

Information  system  users  of  the  system  were  not  sympathetic 
with  conversion  problems  and  continued  to  demand  enhancements.  No 
systems  were  frozen  during  conversion.  Higher-level  management  was 
extremely  interested  and  involved  through  hardware  acquisition  and 
installation.  Thereafter,  there  was  little  interest  or  backir^  for  any 
processes  which  would  have  eased  conversion,  i.e.,  freezing  development. 

Conversion  was  accomplished  in-house.  The  conversion  staff 
lost  personnel  without  replacement  due  to  a  hiring  freeze.  Summer  hire 
students  were  used  as  programmers  but  their  short  employment  period  did 
not  compensate  for  personnel  shortfalls.  In  retrospect,  it  was  recc^nized 
that  some  contractual  support  should  have  been  provided  for  personnel 
loss  contingencies,  even  if  not  exercised. 

Before  conversion  started,  code  conversion  was  expected  to  be 
the  most  difficult  processes  In  fact,  code  conversion  was 
stra^htforward.  However,  old  programs  were  heavily  dependent  on  IBM 
utilities  and  the  conversion  staff  encountered  extreme  problems  in 
applying  UNIVAC  utilities,  which  differed  considerably  from  those  offered 
by  IBM. 

The  IBM  systems  programmers  had  detailed  knowledge  of  the 
source  system  and  were  extremely  helpful  to  the  organization's 
application  programmers.  Target  systems  programmers  were  new  and 
lacked  agency  ins^ht  and  experience.  System  programming  support  to 
the  applications  programmers  dropped  dramatically  during  conversion. 
Associated  problems  in  ddjugging  and  adapting  to  the  target  software 
delayed  conversion  by  approximately  six  months  and  extended  parallel 
testing. 

Conversion  costs  were  not  tracked  but  were  estimated  to  have 
consumed  3  person-years  of  effort. 

MANAGEMENT  LESSONS 


In  summary,  lack  of  planning  led  to  an  underestimation  of 
conversion  resources  and  precluded  early  training  and  conversion  on  the 
RJE  station.  Conversion  managers  did  not  anticipate  the  need  to  handle 
unforeseen  problems  such  as  differences  in  software  utilities  and 
inexperienced  systems  programmers.  These  problems  were  compounded 
by  not  freezing  development  and  incorporating  new  user  enhancements  in 
conjunction  with  the  conversion. 


182 


AGENCY  2  EXPERIENCE 


The  followir^  is  a  case  history  of  a  software  conversion 
experience  that  took  place  from  1974  to  1980  at  a  federal  agency. 

BACKGROUND 

The  agency  operates  a  large  centralized  service  bureau 
computer  system  serving  various  agency  departments  and  other 
government  agencies.  Saturation  caused  the  agency  to  convert  from  an 
IBM  36n/65  to  two  IBM  37^/1 and  then  to  an  AMDAHL  in  1979. 
Approximately  55  percent  of  the  code  was  FORTRAN,  45  percent  PL"*, 
and  5  percent  COBOL.  In  every  case,  migration  of  application  programs 
was  to  code-compatible  machines.  However,  there  were  conversion 
problems  in  converting  to  the  AMDAHL  that  are  useful  as  learning 
vehicles,  particularly  from  the  perspective  of  a  service  bureau  operation. 

THE  CONVERSION 

The  agency  allowed  one  year  for  planning  purposes  but 
considered  that  two  years  would  have  been  better.  The  biggest  problem  in 
conversion  planning  was  obtaining  user's  input.  Neither  users,  nor  anyone 
else,  knew  the  status  of  all  the  available  programs.  Purging  outdated 
code,  old  test  code  and  duplicate  programs  was  a  difficult  exercise. 
Although  users  were  charged  a  pro-rata  fee  for  service  and  machine  time, 
resources  were  not  applied  to  storage.  Hence  there  was  no  incentive  to 
cause  users  to  remove  unwanted  code  or  data  from  the  inventory. 

One  person  was  assigned  to  the  conversion  fuU-time  and 
served  as  project  manager.  While  the  conversion  was  viewed  as 
successful,  it  was  considered  that  better  coordination  and  interaction  with 
users  and  managers  could  have  been  effected  if  more  people  had  been 
dedicated  to  project  management  activities.  Such  assignment  was 
precluded  due  to  the  agency  chargir^  scheme.  User's  charges  were  based 
on  normal,  day-to-day  operating  costs  such  as  machine  use,  line  costs, 
utilities,  and  program mir^  services.  There  was  no  built-in  overhead  to 
cover  project  management  personnel  required  for  software  conversion. 
Continuous  negotiations  had  to  be  conducted  with  users  to  provide  the 
extraordinary  project  management  resources  associated  with  the 
conversion.  Essentially  project  management  resources  were  understaffed. 

Adequate  documentation  on  application  programs  was 
unavailable.  This  condition  was  due  in  part  to  the  nationwide  spread  of 
users  who  were  responsible  for  developing  their  own  application  programs. 
Additionally,  users  continued  to  develop  and  enhance  systems  throughout 
the  conversion.  These  factors,  coupled  with  the  outdated  code  in  the 
inventory,  caused  difficulties  in  developing  software  conversion 
specifications. 
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High  level  management  was  primarily  interested  in  hardware 
procurement  and  installation.  The  next  level  of  management  (functional 
information  system  users)  were  primarily  interested  in  keeping 
applications  under  development 

Some  planning  is  now  in  process  for  the  next  conversion.  The 
use  of  software  standards  is  being  stressed  alor^  with  documentation. 
Given  the  limited  control  the  processing  center  has  over  user's 
applications,  the  achievement  of  acceptable  use  of  software  standards  and 
documentation  was  questionable. 

MANAGEMENT  LESSONS 

In  summary,  there  were  problems  with  high  level  management 
involvement,  user's  support,  program  specifications,  detailed  planning  and 
project  management  resourcing.  Had  these  problems  existed  in  a  non- 
code-compatible  environment,  serious  problems  would  probably  have 
resulted.  The  selection  of  a  code-compatible  machine  resulted  in  the 
conversion  being  accomplished  in  an  acceptable  time.  However,  the 
conditions  that  could  have  caused  problems  for  a  non  code-compatible 
conversion  still  existed. 
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AGENCY  3  EXPERIENCE 


BACKGROUND 

The  agency  is  responsible  for  management  of  world-wide  cai^o 
traffic.  A  significant  functional  area  involves  port  cargo  operations.  For 
some  time  port  cargo  operations  were  supported  by  a  management 
information  system  (MIS). 

Dual  Burroughs  5500  computers  were  operating  at  two  area 
headquarters  locations,  one  on  the  East  Coast,  and  the  other  on  the  West 
Coast.  The  B5500  computers  were  linked  to  IBM  360/20  terminals  located 
at  offices  at  various  ports  (e.g.  Seattle,  New  Orleans)  The  MIS  handled 
movement  control,  manifests,  container  transhipments,  and  other  traffic 
management  applications  generally  oriented  to  export  cargo,  as  well  as 
retrograde  cargo. 

Growth  in  cargo  movement  administration  had  saturated  the 
B5500  computers.  Given  the  age  of  these  computers  and  the  IBM  360/20 
remote  job  entry  (RJE)  terminals,  continued  reliance  on  this  equipment 
posed  a  risk  to  system  reliability.  Software  enhancements  were  difficult 
to  introduce,  particularly  on-line  applications.  While  the  MIS  was 
originally  a  standard  batch-oriented  system,  the  B5500  computers  would 
support  remote  terminals.  Differences  in  the  degree  of  saturation  at  each 
area  headquarters  had  resulted  in  some  capability  for  on-line  applications 
on  the  West  Coast.  However,  aU  applications  were  batch  on  the  East 
Coast,  due  to  the  inability  of  the  B5500  to  process  the  higher  cargo 
volumes  in  an  on-line  mode.  Because  of  these  conditions,  in  the  mid 
197 O's,  the  organization  decided  to  upgrade  the  system  with  the  following 
objectives: 

o       Modem  equipment, 
o       On-Line  applications, 

o      Sufficient  processing  capacity  to  handle  extraordinary 
cargo  movements  loads, 

o      Improved  redundancy  and  reliability, 

o      Standard  applications  on  both  coasts, 

o      Stand  alone  capability  at  various  ports. 

THE  CONVERSION 

Planning  started  in  the  summer  of  1978.  Honeywell  Level  6 
computers  were  selected  as  the  target  hardware.  The  initial  planning 
resulted  in  a  systems  conc^t  which  was  approved  in  October  1978.  The 
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concept  called  for  replacement  of  the  B5500  computers  as  soon  as 
possible  with  dual  Honeywell  Level  6  computers  at  the  two  area 
headquarters,  and  replacement  of  the  IBM  360/20  terminals  with  single 
Honeywell  Level  6  computers  The  concept  also  provided  for  transfer  of 
some  of  the  non-time  sensitive,  historical,  high-volume  applications  to  the 
agency  headquarters  for  processing  on  a  HIS  6060  mainframe  which  was 
already  in  place.  The  combination  of  modem  hardware  and  revised 
application  processing  covered  all  system-upgrade  objectives. 

After  the  concept  had  been  approved,  detailed  planning 
commenced  in  early  1979  and  continued  for  six  to  nine  months  Thorough 
planning,  early  in  the  project,  was  recognized  as  necessary  to  successfully 
execute  the  project.  This  planning  was  accomplished  by  a  management 
team  which  was  organized  for  the  purpose.  Planning  was  a  continuing 
function,  ongoing  midway  through  Uie  conversion,  and  was  expected  to 
continue  until  the  conversion  was  completed.  There  were  always 
unforeseen  events  which  had  to  be  compensated  for  and  which  required 
revised  plans. 

Automated  (PERT)  planning  tools,  available  through 
Honeywell,  were  tried  without  success.  Planners  felt  that  the  extra 
effort  to  enter  all  of  the  project  data  did  not  result  in  automated  planning 
aids  which  were  any  better  than  those  manually-produced. 

PROJECT  MANAGEMENT 

The  management  team  was  essentially  a  project  management 
effort.  Originally  it  was  envisioned  that  the  team  could  be  dissolved  after 
it  had  planned  the  schedule  and  identified  all  activities  and  actions  which 
had  to  be  accomplished  (e.g.,  equipment  selection  and  acquisition, 
software  conversion,  communications  specifications,  and  training).  The 
team  was  temporarily  dissolved,  but  it  soon  became  apparent  that  the 
project  was  losing  coordination  and  direction.  Formal  project 
management  was  reconstituted  on  a  permanent  basis  before  any  adverse 
developments  occurred. 

SOFTWARE 

There  were  over  900  source  programs  to  convert.  Most  were 
written  in  COBOL-64  and  68  except  for  a  few  FORTRAN  applications. 
No  new  user  enhancements  were  introduced  during  the  conversion.  The 
conversion  was  essentially  a  line  for  line  conversion  modified  by  introduc- 
tion of  some  Honeywell  input-output  and  transaction  handler  routines  used 
as  a  matter  of  expediency.  An  automated  Honeywell  tool  was  used  to 
convert  B5500  applications  to  be  transferred  to  the  HIS  6060  mainframe. 
This  tool  was  modified  in-house  to  convert  the  target  software  to  be 
placed  on  HIS  Level  6  computers.  New  enhancements  and  redesigns, 
primarily  on-line  applications,  were  scheduled  for  development  after  the 
conversion. 
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The  old  B55<^n  system  documentation  was  often  incomplete, 
causing  problems  in  planning  and  in  developing  conversion  specifications. 
The  new  system  will  be  completely  documented  using  government 
standards.  Documentation  was  ongoing  concurrent  with  software 
conversion. 

MANAGEMENT  AND  USER'S  INVOLVEMENT 

Top  agency  executives  backed  the  project  from  its  inception. 
Management  understood  the  operational  advantages  of  a  speedy 
conversion  and  the  problems  associated  with  the  conversion  This 
management  support  was  also  conducive  to  good  functional  user's 
cooperation.  The  project  management  interacted  regularly  at  all  user 
and  management  levels  to  keep  these  parties  appraised  of  progress  arrf 
involved  in  meeting  requirements. 

FUNDING  AND  RESOURCES 

Because  the  project  was  well  planned  in  the  beginning, 
adequate  resources  were  identified,  programmed  and  budgeted  to  support 
the  equipment,  communication,  site  preparation,  and  training.  The 
software  conversion  was  accomplished  with  in-house  resources. 

STATUS 

Preparation  for  conversion  started  in  the  fall  of  1979.  Actions 
during  this  phase  included  assembling  and  modifying  the  software 
conversion  tools,  site  preparation  and  installation  of  target  computers. 
Conversion  actually  started  in  early  1980.  All  conversion  was  to  be 
completed  by  late  1981.  Individual  subsystems  would  undergo  parallel 
testing  until  all  users  and  manners  were  satisfied.  Parallel  testing 
operations  would  be  supported  by  existing  resources.  As  of  January  1981, 
the  project  was  on  schedule.  This  condition  was  primarily  due  to  good 
planning,  active  project  management  and  user  and  management 
involvement  and  support.  The  source  computers  were  scheduled  for 
release  in  the  fall  of  1981  at  Western  Area  and  the  ^ring  of  1982  at 
Eastern  Area. 

MANAGEMENT  LESSONS 

This  case  history  illustrates  that  the  advantages  of  achieving 
high  level  management  and  functional  user's  support,  develc^ment 
freezing,  good  planning,  and  adequate  project  management  can  result  in 
an  efficient  software  conversion  accomplished  on  time  and  within  bucket. 
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AGENCY  4  EXPERIENCE 


BACKGROUND 

The  federal  agency  interviewed  was  responsible  for  bi-monthly 
mailings  of  computer  output,  and  had  definite  schedule  restrictions.  The 
agency  was  running  its  systems  on  old  UNIVAC/Spectra  hardware.  During 
the  1975  time-frame,  management  decided  that  the  system  was  saturated 
and  further  enhancements  of  the  current  system  would  no  longer  be 
effective.  A  Honeywell  computer  was  selected  as  the  target  hardware. 

The  Spectra  was  running  over  20  systems  consisting  of  270,000 
lines  of  assembler  code,  and  30,000  lines  of  COBOL.  Conversion  was  to 
be  to  COBOL/68.  The  agency  had  adequately  documented  its  system 
according  to  FTPS  PUB-38. 

THE  CONVERSION 

A  conversion  project  team  with  19  programmers/analysts  was 
organized.  Tasks  included  conversion,  maintenance,  and  operations  with 
50  percent  effort  on  conversion  and  50  percent  on  maintenance. 

One  special  consideration  and  concern  in  this  project  was  the 
conversion  of  compressed  assembler  code  with  over  600  file  formats  and 
100  different  record  types.  Because  record  control  bits  were  used  to 
identify  field  length  and  absence  of  data,  the  conversion  from  EBCDIC  to 
Honeywell  BCD  was  of  critical  concern. 

Contractor  services  for  conversion  assistance  was  for  a  cost 
plus  fixed  fee  (CPFF)  contract  at  a  cost  of  $1.7  million.  Assembler 
Lar^uage  to  COBOL/68  automated  tools  were  developed  by  the 
contractor.  These  tools  were  fairly  successful  but  manual  coding  for 
special  extensions  was  still  required.  Another  tool  was  used  to  compress 
data  files. 

Of  the  twenty  systems  to  be  converted  the  ten  smallest  were 
converted  first.  During  their  conversion,  significant  problems  became 
apparent  Some  converted  programs  were  far  less  efficient  on  the  target 
hardware  than  the  source  hardware.  Midway  through  the  conversion 
effort,  target  hardware  was  changed  to  an  IBM  3231,  and  the  remaining  10 
systems  were  converted  to  this  hardware  The  IBM  software  was 
compatible  with  that  of  the  source  software  and  conversion  was  much 
simpler. 

Prior  to  the  conversion,  the  agency  had  provided  back-up 
services  with  a  time-sharir^  firm  in  case  conversion  hardware  facilities 
went  down.  The  agency  was  also  prepared  to  keep  and  maintain  the  old 
Spectra  hardware  until  all  systems  were  converted. 
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MANAGEMENT  LESSONS 


While  adequate  planning  was  spent  in  converting  master  files 
and  development  of  test  data,  little  effort  was  expended  in  developing  and 
analyzing  benchmark  criteria.  This  was  exemplified  by  one  system's  14 
hour  run  time  on  Honeywell  target  hardware  compared  to  55  minutes  on 
the  IBM  target  hardware. 

Software  conversion  managers  did  not  participate  in  hardware 
procurement  decisions  In  both  instances  (conversion  to  Honeywell  and  to 
the  IBM),  the  software  manager  was  notified  after  the  hardware  was 
procured.  This  left  inadequate  time  for  planning.  The  software  project 
manager  was  also  unable  to  prevent  users  from  ordering  enhancements. 
The  conversion  team  was  able  to  deal  with  this,  but  the  project  would 
have  been  easier,  had  software  been  frozen.  Upper  management  did 
intercede,  at  times,  when  user's  requests  were  unduly  affecting  the 
conversion  effort. 

Financial  planning  was  also  inadequate.  Thoi^h  the  contractor 
came  within  budget,  there  would  have  been  a  cost-overrun  had  the  target 
hardware  not  been  changed  to  a  code-compatible  configuration. 
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AGENCY  5  EXPERffiNCE 


BACKGROUND 

The  organization  interviewed  was  responsible  for  maintaining 
up-to-date  information  on  world-wide  activities,  and  distributing  this 
information  to  field  offices  around  the  world.  This  organization  was  one 
element  of  many  within  the  agency. 

The  information  files,  which  constituted  the  bulk  of  the 
automated  effort,  were  extensions  of  applications  that  had  been 
maintained  for  many  years  on  punch  card  accounting  machines.  These 
files  were  migrated  to  an  IBM  "60/40,  which  was  acquired  in  1969,  and 
placed  on  a  DBMS. 

In  1973,  the  vendor  supporting  the  DBMS  cancelled  support. 
This  resulted  in  a  decision  to  convert  to  another  DBMS.  Conversion  was 
to  be  completed  within  6  months. 


Situation  at  Project  Initiation 

o  Batch  applications,  approximately  75  percent  of  a 
sequential  workload,  were  running  on  an  IBM  360/40  3 
shifts  a  day,  7  days  a  week. 

o  No  programmers,  users  or  analysts  were  trained  in  the 
new  DBMS. 

o       There  was  a  programmer  and  analyst  staff  of  18. 

o  The  staff,  which  had  recent  conversion  experience 
before  was  still  in  place. 

o  High-level  management  agreed  to  halt  all  enhancements 
to  existing  applications  This  caused  user's  support  of 
the  project,  at  least  to  the  extent  that  they  couldn't 
pressure  the  ADP  staff  to  continue  enhacements  and  new 
developments. 

THE  CONVERSION 

A  straight  redes^n  conversion  was  planned  without 
incorporation  of  new  user's  enhancements. 

A  project  management  team  was  established.  The  supervisor 
of  the  analysis  and  programming  section  was  the  team^iead,  assisted  full- 
time  by  the  lead  systems  analyst.  The  most  competent  developmental  and 
maintenance  programmers  (approximately  four)  were  added  to  the  team 
full-time.  One  input-output  control  technician  was  also  added  full-time. 


190 


The  complete  lack  of  any  staff  trained  in  the  new  DBMS  was  a 
serious  problem.  This  problem  was  compounded  by  the  lack  of  experience 
in  newly-trained  programmers,  and  the  short  project  deadline. 
Coordination  with  a  mobile  training  team  revealed  locations  where  new 
DBMS  training  was  scheduled.  Coordination  with  organizations  scheduled 
to  receive  new  DBMS  training  produced  a  few  slots  to  train  project  team 
members  as  early  as  possible.  The  training  team  also  cooperated  by 
adjusting  their  schedule  to  provide  on-site  analyst,  programmer  and  user 
training  to  most  of  the  remaining  conversion  team  approximately  one 
month  after  project's  initiation.  This  was  aifficient  to  accomplish  the 
conversion. 

No  contractor's  assistance  was  used.  The  most  complex 
system  was  chosen  for  the  initial  conversion  It  was  assumed  that  if  the 
project  management  team  could  convert  that  application,  the  remaining 
applications  would  be  problem  free  This  approach  produced  successful 
results. 

Freezing  new  user's  enhancements  and  system  development 
provided  enough  computer  time  for  training  and  conversion  except  for  two 
two-week  periods  late  in  the  conversion  process.  Arrar^ements  were 
made  with  back-up  computer  facilities  to  provide  processing  time  during 
those  two  week  periods.  Small  teams  of  computer  operators, 
maintenance  programmers  and  a  system  programmer  were  dispatched  to 
run  production  reports  and  applications. 

At  the  conclusion  of  the  six-month  period,  the  conversion  was 
complete.  However,  all  converted  applications  had  not  processed  in 
parallel  for  a  two-month  period  to  allow  debugging  and  assure  quality 
controL  Parallel  testing  operations  continued  for  two  additional  months. 
Moreover,  while  documentation  was  an  ongoing  effort  during  conversion, 
full  sets  of  systems  documentation  were  not  completed  until 
approximately  four  months  after  the  conversion  effort. 

Unbudgeted  conversion  costs  were  mostly  absorbed  by 
cancelling  or  limiting  projected  travel  and  carefully  monitoring  operating 
costs  for  the  remainder  of  the  fiscal  year.  A  mid-year  request  for 
shortfall-funding  provided  the  additional  funds  necessary  to  cover  all 
costs. 

MANAGEMENT  LESSONS 

This  conversion,  which  was  essentially  accomplished  on  time, 
received  high-level  management  support,  and  benefited  from  the  freezing 
of  new  enhancements  and  development  Full-time  project  management 
and  an  experienced  staff  had  the  insight  and  authority  to  overcome 
problems  associated  with  a  short  conversion  deadline  and  inadequate 
training. 


191 


AGENCY  6  EXPERIENCE 


BACKGROUND 

In  1973,  the  agency  developed  15  administrative  data  base 
management  system  applications  supporting  ^ency  training.  These 
applications  were  run  at  night  as  batch  on  a  Honeywell  (HIS)  635 
computer,  the  daytime  hours  being  primarily  reserved  for  on-line  student 
use  of  the  hardware  system.  There  was  no  requirement  for  student  access 
to  the  administrative  applications.  However,  the  staff  and  faculty  did 
require  access  at  times  during  the  day. 

Besides  the  training-related  administrative  systems,  there 
were  approximately  300  various  agency  installation-unique  COBOL 
programs  which  were  processed,  as  required,  at  night  on  the  HIS  635. 

By  1974,  the  on-line  demands  of  all  users  exceeded  the 
capacity  of  the  HIS  635  system.  Efforts  to  upgrade,  sole  source,  were 
denied  and  competitive  hardware  procurement  and  software  conversion 
contracts  were  pursued.  To  resolve  saturation  problems  the  agency  was 
permitted  to  upgrade  the  hardware  to  an  HIS  6080  System  as  an  interim 
measure  pending  completion  of  the  competitive  procurement. 

THE  CONVERSION 

UNIVAC  won  both  the  hardware  and  training-related 
administrative  application  conversion  contracts.  A  UNIVAC  1100/11  was 
selected  to  process  the  COBOL  and  administrative  applications.  A 
UNIVAC  1100/12  was  selected  to  provide  time  sharing  service  to  the 
student  body.  Separate  from  UNIVAC,  another  contractor  was  awarded 
the  contract  to  convert  the  agency  unique  COBOL  programs. 

It  was  decided  to  redesign  the  administrative  DBMS 
applications  to  another  DBMS  offered  by  UNIVAC  and  to  convert  the 
COBOL  programs  line  by  line. 

There  were  problems  with  development  of  the  UNIVAC  DBMS 
software  conversion  specifications.  Users  were  not  interested  in 
collaborating  in  the  specification  definition  effort.  They  were  relatively 
satisfied  with  the  existing  DBMS  applications.  Since  the  input  and  output 
would  remain  essentially  unchanged,  the  users  were  not  inclined  to 
emphasize  to  the  conversion  planners  the  subtle  but  important  insights  or 
considerations  relating  to  timing  of  reports  or  relationships  of  certain 
reports  to  others.  While  these  relationships  were  probably  understood  by 
the  in-house  team  that  developed  the  specifications,  they  were  not 
adequately  stressed,  and  ultimately  not  comprehended  by  the  contractor. 
Futhermore,  the  original  software  documentation  was  outdated  or 
nonexistent.  This  condition  contributed  to  conversion  specification 
inadequacies. 
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Conversion  from  one  major  DBMS  to  another  resulted  in  an 
extremely  complex  software  design  effort  The  complexities  of  the 
project,  when  coupled  with  specification  shortfalls,  resulted  in  disputes 
with  the  contractor,  project  slippage  and  generated  considerable 
unanticipated  involvement  in  the  conversion  process  by  the  in-house  staff 
of  programmers  and  analysts. 

The  agency  insisted  that  the  UNIVAC  contractor  develop 
complete  software  documentation  based  on  FIPS  Publication  38.  The 
contractor  sought  release  from  this  requirement  Disagreement  over 
contractual  conditions  relating  to  documentation  requirements  and 
specification  shortfalls  resulted  in  slippage  of  the  conversion  effort 
approximately  9  months  past  release  of  the  HIS  6080.  This  condition 
precluded  parallel  testing  of  some  applications. 

Disagreement  over  contractual  levels  of  effort  with  the 
second  conversion  contractor  over  a  lack  of  COBOL  programs 
documentation  led  to  disputes  which  resulted  in  contractor  conversion  of 
approximately  90  percent,  rather  than  all  of  the  software.  Twenty-four, 
or  10  percent  of  the  applications,  were  converted  in-house.  The 
contractor  did  not  provide  any  documentation.  The  agency  intended  to 
write  the  documentation  in-house  but  recognized  that  in  reality  some  or 
all  of  the  program  documentation  would  never  be  developed. 

It  was  estimated  that  all  software  conversions  could  have  been 
accomplished  in-house  for  the  same  effort  spent  in  resolving  all 
contractual  software  conversion  issues. 

Analyst  and  programmer  training  on  the  new  system  was 
considered  sufficient  but  was  conducted  too  early.  Maintenance 
programmers  lost  their  technical  edge  due  to  too  much  elapsed  time 
between  training  and  delivery  of  the  contractually-developed  DBMS 
software  for  their  maintenance. 

Formal  processes  were  established  and  adhered  to  regarding 
review  of  contractor  performance  and  recording  user  acceptance  of 
converted  applications.  These  processes  assisted  in  conversion  by 
improving  understanding,  reducing  slippage  and  monitorir^  costs. 

FuU-time  project  management  had  not  been  exercised  in  the 
pre-conversion  phases  and  resulted  in  planning  shortfalls  (e.g.,  inadequate 
software  specifications  and  training).  To  remedy  this  the  software 
conversion  process  operated  under  the  project  manager  concept.  This  was 
considered  invaluable  in  resolving  unanticipated  issues.  It  was  also 
considered  essential  that  a  contractor  have  a  full-time  project  manager 
throughout  the  project.  This  had  been  the  case  until  the  contract  was 
extended  to  compensate  for  slippage.  At  that  time,  the  contractor 
project  manager's  position  was  abolished  in  an  attempt  to  reduce  costs. 
Thereafter,  internal  contractor  coordination  and  management  problems 
developed  and  adversely  impacted  productivity. 
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MANAGEMENT  LESSONS 


This  case  history  Illustrates  the  need  to  have  software  well 
documented.  Documentation  facilitates  conversion  planning,  development 
of  software  specifications  and  contractual  statements  of  work.  The  need 
to  maintain  full-time  project  management  throughout  a  conversion  was 
also  shown.  Management  recognized  the  need  for  software  documentation 
but  experienced  problems  with  the  contractors  who  resisted  delivery  of 
documentation. 
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AGENCY  7  EXPERIENCE 


BACKGROUND 

The  agency  is  responsible  for  the  regulation  of  a  major 
industry.  To  administer  the  programs  necessary  for  compliance  with  its 
regulatory  responsibility,  the  agency  utilizes  the  services  of  its  data 
processing  division  to  track  various  equipment,  licenses,  and  applications, 
monitor  violations,  and  other  administrative  functions  such  as  payroll  and 
personneL 

Aging  hardware  and  systems  growth  resulted  in  a  conversion 
from  a  UNIVAC  3  to  a  Honeywell  6023  computer  system.  Conversion 
consisted  of  some  30  systems  encompassing  260  programs  written  in  SALT 
(assembler)  and  translated  into  COBOL. 

Planning  for  the  conversion  began  in  late  1973.  By  that  time 
replacement  parts  for  the  UNIVAC  3  had  become  difficult  to  obtain  and 
often  required  cannabilizing  other  UNIVAC  3  systems.  The  workload  had 
reached  a  point  that  the  agency  rented  time  on  a  UNIVAC  1108  to  handle 
its  UNIVAC  3  overflow.  The  agency  developed  specifications  for  its 
conversion  after  holding  discussions  with  conversion  specialists.  Separate 
hardware  and  software  conversion  RFPs  were  prepared  and  released  in 
1975.  Honeywell  won  the  hardware  selection  while  another  contractor 
was  awarded  the  software  conversion  project. 

THE  CONVERSION 

Under  the  terms  of  the  software  RFP  the  agency  was  to 
provide  system  documentation,  programs,  test  data  and  machine  time  to 
contractors.  The  specifications,  however,  allowed  the  contractor  to 
request  virtually  unlimited  levels  of  detailed  documentation,  and  that  test 
data  be  in  contractor  specified  format.  These  conditions  placed 
unanticipated  workloads  on  the  conversion  project  team  Program 
acceptance  was  based  upon  successful  execution  of  90  percent  of  code. 
However,  no  performance  specifications  were  required.  As  a  result, 
processing  that  had  previously  required  two  shifts  on  the  UNIVAC 
required  three  shifts  on  the  Honeywell  This  condition  indicated  that  the 
software  was  inefficient  in  design. 

Some  2,000  data  files  ranging  from  2,000  records  to  7-" 
million  records  per  file  were  required  to  be  converted.  To  convert  these 
files,  the  agency  had  to  temporarily  acquire  a  minicomputer  at  an 
additional  cost  of  $25,000.  A  "bit  to  byte"  format  change  had  to  be 
accomplished  because  of  software  differences  between  source  and  target 
systems  and  caused  considerable  problems  for  the  agency. 

The  conversion  staff  consisted  of  seven  full-time  and  two 
part-time  personnel  who  handled  the  data  conversion  effort  along  with 
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two  full-time  (on-site)  contractor  personnel  for  12  months.  The  number 
of  contractor  personnel  working  off-site  was  unknown.  What  was  initially 
estimated  as  a  9-12  month  conversion  effort  actually  required  two  years 
(in  addition  to  one  year  spent  in  planning  and  procurement)  for  a  total  of 
21  man-years  of  effort.  Both  the  schedule  and  budget  ($1  miUion)  were 
overrun. 

Because  of  continuing  growth,  the  agency  again  upgraded  to  a 
Honeywell  6640  in  1978,  and  in  late  1979  upgraded  tg  a  Honeywell  6660. 
These  migrations,  being  code-compatible,  were  accomplished  with 
negligible  problems. 

While  existing  systems  and  operations  documentation  was 
adequate,  the  contractor  was  required  only  to  document  the  operational 
procedures  (run  manuals)  for  the  H6023.  System/program  documentation 
was  left  up  to  the  agency. 

There  were  no  ongoing  plans  for  future  conversions  although 
the  £^ency  had  upgraded  hardware  twice  since  the  conversion  to  the 
Honeywell  6023. 

MANAGEMENT  LESSONS 

The  conversion  and  budget  overrun  were  indicative  of  poor 
initial  planning.  Also,  the  software  conversion  contract  was  constructed 
to  the  contractor's  advantage  which  adversely  impacted  the  conversion 
staff  efforts.  This  resulted  in  loss  of  project  management  control  over 
the  contractor,  produced  programs  with  exceptional  run  times  (indicative 
of  poor  software  design),  and  caused  delivery  of  inadequate  software 
documentation. 


196 


AGENCY  8  EXPERIENCE 


The  followir^  is  a  case  history  of  a  software  conversion 
experience  at  a  federal  agency  that  started  in  late  1976  and  was  still 
ongoing  in  Fdjruary,  1981. 

BACKGROUND 

The  agency  was  heavily  involved  in  simulation  and  modelling. 
There  were  approximately  twenty  major  models  running  on  a  UNIVAC 
1108  using  EXEC  8,  Level  33.  The  models  were  large-scale,  mostly 
written  in  FORTRAN,  with  some  COBOL  used  The  twenty  major  models 
consisted  of  approximately  200,000  lines  of  code  in  FORTRAN  and  50,000 
lines  in  COBOL.  Other  models  and  systems  doubled  the  lines  of  code  to 
approximately  one-half  million. 

In  late  1976,  ADP  personnel  determined  that  the  system  was 
saturated;  models  were  taking  too  long  to  run.  A  hardware  RFP  was 
released  in  February  1979.  UNIVAC  won  and  a  UNIVAC  1182  was 
installed.  The  source  and  target  system  machines  were  expected  to  run  in 
parallel  for  approximately  six  months.  The  RFP  required  a  pre- 
instaUation  test  facility  nine  (9)  months  before  the  new  mainframe  was 
installed. 

THE  CONVERSION 

Prior  to  releasing  the  RFP,  aU  models  were  scanned  and  code 
was  analyzed  for  vendor  specific  extensions.  Problems  were  noted  in  two 
areas: 

o       Word  size, 

o       Representation  of  character  type  data. 

It  was  decided  that  software  conversion  would  be  done  by  in- 
house  personnel  Contractors  would  require  too  long  to  familiarize 
themselves  with  the  models  Agency  functional  users  were  also  the 
programmers,  were  the  most  familiar  with  their  own  models,  and 
considered  best  able  to  perform  the  conversion.  Additionally, 
documentation  was  inadequate  and  outdated,  adding  to  the  difficulties  of 
indoctrinating  contractors  on  mechanisms  of  the  models.  Automated 
tools  were  also  examined  but  determined  to  be  ineffective. 

A  detailed  software  conversion  requirements  study  was  not 
performed.  In-house  personnel  were  expected  to  handle  the  conversion  in 
addition  to  their  regular  duties;  no  specific  planning  or  thought  was 
accomplished  to  address  the  difficulties  associated  with  this  option. 
Software  conversion  was  thought  simple  and  no  major  problems  were 
expected.  A  project  team  was  not  organized,  and  no  cost  estimation  was 
performed 
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The  conversion  itself  proved  to  be  straight  forward  because  a 
code-compatible  machine  was  selected.  UNIVAC  was  the  only 
respondent  Operating  systems  were  very  similar  and  few  problems  were 
encountered  during  the  conversion.  However,  management  personnel  did 
not  plan  adequately  for  site  preparation.  Because  of  delays  in  getting 
GSA  approval  for  site  preparation,  the  1182  had  to  be  installed  in  a 
UNIVAC  facility.  GSA,  as  of  February  1981,  had  yet  to  approve  the  site 
preparation. 

MANAGEMENT  LESSONS 

The  agency  was  extremely  fortunate  in  obtaining  a  code- 
compatible  machine  In  spite  of  a  previous  conversion  experience  that 
had  proven  very  difficult,  conversion  requirements  were  relegated  to  a 
minor  role.  No  planning  or  cost  estimation  was  performed. 

Also,  the  lack  of  adequate  model  documentation  would  have 
impacted  on  conversion  if  a  non  code-compatible  machine  had  been 
selected.  The  models,  maintained  by  users  who  understood  the  code  ami 
model  scheme,  contain  modifications  that  were  rarely  documented. 
Despite  the  potential  conversion  problems  posed  by  this  lack  of 
documentation,  program  documentation  was  not  being  pursued. 


198 


AGENCY  9  EXPERIENCE 


BACKGROUND 

This  agency  was  in  the  planning  and  procurement  stage  of  a 
software  conversion  to  meet  increased  mission  needs  and  requirements. 
Their  applications  were  being  processed  on  a  variety  of  hardware 
configurations  within  the  agency,  consisting  of  a  Honeywell  635,  two  IBM 
3032s,  a  HoneyweU  6000  and  a  Honeywell  6060.  In  addition,  a  DEC2020 
and  five  PDP  ll/70s  were  included  in  their  hardware  inventory. 

PLANNING 

Although  the  planning  and  procurement  process  had  been  on- 
going for  two  and  a  half  years,  the  RFP  has  not  yet  been  awarded;  thus 
target  hardware  was  still  unknown  as  of  February  1981. 

It  was  estimated  that  the  conversion  effort  itself  would  take 
two  years  and  that  the  total  conversion  process  including  planning  and 
procurement,  would  last  four  and  a  half  to  five  years. 

Various  off-the-shelf  automated  tools  were  currently  being 
evaluated  to  handle  the  common  compiler  driver  language  types.  For 
example,  plans  called  for  automatically  converting  COBOL/68  to  the 
more  efficient  COBOL/74.  In  addition  to  COBOL  their  basic  software 
packages  in  use  included  FORTRAN,  PL/1,  SIMSCRIPT,  GYPSIE 
(graphics),  SPSS,  as  well  as  a  variety  of  ad  hoc  query/update  routines. 

STAFFING 

Although  the  bulk  of  the  conversion  was  to  be  accomplished  by 
in-house  personnel,  provisions  called  for  a  one-year  task  order  type 
contract  to  be  awarded  for  assistance  as  needed,  during  the  conversion.  It 
was  projected  that  one  third  of  the  conversion  would  be  accomplished  by 
the  use  of  automated  tools,  one  third  through  recoding,  and  the  remaining 
one  third  would  require  some  degree  of  redesign. 

There  were  675  people  assigned  to  the  agency  data  center,  600 
of  whom  were  programmers.  Approximately  100  project  officers,  and 
their  staffs  would  be  responsible  for  actually  accomplishing  the 
conversion.  Each  project  officer  would  be  assigned  responsibility  for  one 
or  more  systems.  Reporting  to  each  project  officer  would  be  a  variety  of 
programmers  and  analysts.  It  was  projected  that  200  people  would  be 
involved  at  any  one  time  in  conversion  duties.  Two  miUion  dollars  was 
budgeted  for  an  estimated  400  man-year  effort 
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MANAGEMENT  LESSONS  OR  OBSERVATIONS 


For  a  conversion  of  this  magnitude,  it  was  planned 
significantly  far  enough  in  advance  to  allow  adequate  time  for  staffing, 
identifying,  and  evaluating  activities.  However,  two  major  shortfalls 
were  observed: 

(1)  The  budget  of  $2  million  appeared  extremely  low.  A 
more  realistic  budget  was  estimated  at  $6  -  9  million. 

(2)  User  and  system  documentation  was  not  satisfactory. 
Although  standards  were  being  examined,  this  critical  area  had  not  been 
stressed.  Lack  of  acceptable  documentation  would  most  probably 
complicate  future  conversion  efforts. 
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AGENCY  10  EXPERIENCE 


BACKGROUND 

The  agency  interviewed  was  responsible  for  maintaining  an 
inventory  of  equipment  and  supplies  at  locations  throughout  the  world. 
The  agency  maintained  statistics  on  equipment  failure,  and  adjusted  the 
maintenance  schedule  as  indicated  by  these  statistics.  Programs  were 
written  in  COBOL  and  Assembler,  and  the  data  base  management  system 
was  TOTAL  7.  The  primary  environment  was  in  on-line/real  time  mode. 

Management  decided  to  upgrade  the  system  in  late  1977,  and 
plans  were  made  to  release  an  RFP  to  procure  new  equipment.  The 
source  machines  were  IBM  360/40's.  IBM  4331  machines  were  selected  as 
replacements. 

THE  CONVERSION 

Approximately  two  years  of  planning  was  performed  prior  to 
release  of  the  Requests  for  Proposals.  Durir^  this  planning  phase,  though 
target  hardware  was  unknown,  the  following  activities  were  performed: 

o  A  project  management  team  was  assembled, 

o  Programs  were  inventoried, 

o  Schedules  and  milestones  were  determined, 

o  Management  hierarchy  was  developed, 

o  It  was  determined  that  conversion  would  be  performed 
in-house  by  users  (programmers  and  functional  users 
were  the  same), 

o       Formal  test  procedures  were  developed. 

The  conversion  went  fairly  smoothly.  Software  was  not 
completely  frozen,  however,  and  some  incorporation  of  new  user 
enhancements  was  accomplished.  Some  problems  were  encountered  with 
vendor  extensions  operating  on  the  360/40's.  Weekly  meetings,  held  with 
the  project  management  team  and  programmers,  kept  all  participants 
aware  of  problems  that  other  personnel  encountered. 

At  the  conclusion  of  the  conversion,  the  ^ency  initiated  a 
system  to  examine  both  the  positive  and  negative  aspects  of  the 
conversion  in  the  interests  of  facilitating  future  conversion  efforts. 
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MANAGEMENT  LESSONS 


The  major  shortfall  noted  in  this  conversion  effort  was  a  lack 
of  cost  analysis  and  accounting.  Though  progress  was  tracked,  costs  were 
not  Thus,  the  agency  had  no  detailed  knowledge  of  the  actual  conversion 
costs  to  use  in  planning  and  estimating  future  conversions. 

Planning  activities  appeared  to  be  adequate  and  these  plans 
were  implemented  during  the  conversion.  The  following  activities  were 
cited  as  being  beneficial  to  the  effort: 

o       Developing  bar  charts  depicting  milestones;  these  were 
easy  to  follow. 

o       Developing  and  implementing  a  conversion-reporting  and 
management  hierarchy;  personnel  knew  who  to  report  to. 

o       Holding  regular  meetings;  information  was  disseminated 
to  the  staff. 

o       Availability  of  adequate  documentation. 


202 


AGENCY  11  EXPERffiNCE 


BACKGROUND 

In  June  1981,  a  federal  agency  was  in  the  planning  and 
preparation  stage  of  a  software  conversion.  Due  to  problems  with  the 
aging  CDC  3300  computer,  the  agency  was  preparing  to  convert 
applications  to  a  AMDAHL  470V/7A  computer. 

PLANNING  AND  PREPARATION 

The  agency  planned  to  convert  600  programs  estimated  at 
700,000  lines  of  code  encompassing  approximately  24  major  applications. 
All  applications  were  business-oriented  in  nature.  Processing  was  batch 
but  was  expected  to  shift  toward  some  on-line  DBMS  with  the  recent 
acquisition  of  IDMS  on  the  AMDAHL. 

Due  to  hiring  freezes  and  budget  constraints,  the  ADP  staff 
was  short  of  six  full-time  program mer/analysts.  Because  of  this 
manpower  shortage  the  agency  was  conducting  preliminary  negotiations 
for  contractor's  conversion  assistance.  The  contractor  would  have 
responsibility  for  selection  and/or  development  of  any  automated  tools  to 
be  used. 

The  user's  community,  consisting  of  14  major  functional  users 
had  been  notified  of  the  upcomir^  conversion.  Functional  users  were 
cooperative  and  constructive  but  plans  did  not  anticipate  a  heavy  user 
involvement  in  the  conversion.  Current  plans  called  for  off-site  unit 
testing  at  another  computer  facility,  with  system  and  parallel  testing 
being  conducted  on  the  AMDAHL. 

The  conversion  manager  was  not  assigned  full-time  and  had  to 
direct  not  only  the  conversion  project  but  also  conduct  normally  assigned 
duties  as  welL 

The  team  had  no  prior  conversion  experience,  and  as  a  result, 
no  comprehensive  conversion  plan  was  developed.  Although  the  planning 
process  was  still  being  formulated,  the  entire  scope  of  the  planning  effort 
had  not  been  determined.  It  was  estimated  the  conversion  effort, 
excluding  planning,  would  take  18  months,  and  that  the  total  conversion 
process,  including  planning  and  preparation,  would  take  2  and  a  half  years. 

MANAGEMENT  OBSERVATIONS 

Considering  the  scope  of  this  conversion,  this  agency  did 
reasonably  well  in  their  planning,  preparation  and  identification  of  many 
potential  conversion  problem  areas.  They  assigned  conversion  priorities. 
They  recognized  the  importance  of  freezing  software  development  and 
maintenance  but  were  also  aware  that  the  demands  and  mandates  of  users 
would  likely  preclude  any  total  freeze.  They,  therefore,  instituted  change 
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control  procedures  to  facilitate  conversion  with  new  user  enhancements 
where  freezir^  could  not  be  accommodated.  Moreover,  their  lack  of 
conversion  experience  forced  them  to  recognize  the  need  for  contractor's 
assistance.  However,  lack  of  conversion  experience  coupled  with  a  non 
full-time  conversion  manager  resulted  in  some  problem  areas  being 
overlooked.  Amor^  these  were: 

o  Selection  of  conversion  technique(s)  still  remained  to  be 
resolved  (i.e.,  determining  the  programs  that  lend 
themselves  to  translation  by  automated  tools,  recoding, 
or  that  will  require  a  complete  redesign;  particularly  in 
view  of  the  recent  acquisition  of  IDMS). 


o  Data  communications  and  its  attendant  requirements 
with  agency  RJE  stations  were  completely  overlooked. 

o  Adequate  training,  critical  to  a  smooth  and  successful 
conversion,  especially  when  converting  to  non  code- 
compatible  hardware,  had  not  been  planned. 

o  No  overall  top  management  conversion  plan  had  been 
developed.  Rather,  planning  had  been  fragmented. 

o  No  contingency  planning  had  been  developed  (e.g., 
determinir^  how  ttie  agency  would  cope  with  losses  or 
transfers  in  team  and  staff  personnel). 
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Activity 


Distinct  software  conversion  work  that  is 
accomplished  within  a  phase;  examples  of 
activities  would  be  organizing  a  software 
conversion  team,  budgeting  for  software 
conversion. 


Application  Programs 


Programs  developed  for  functional  users;  to  be 
differentiated  from  system  (operating)  programs. 


Application  System 


One  or  more  applications  programs  which  together 
form  an  information  system  for  an  agency. 
Examples  are  payroll,  personnel,  supply  inventory, 
equipment  maintenance. 


Automated  Tool 


Software  to  aid  in  software  conversion  by 
convertir^  some  or  all  of  the  old  source  software 
to  the  target  software.  An  automated  tool  could 
also  be  used  in  an  intermediate  step,  e.g., 
converting  assembly  lar^uage  to  COBOL  on  a 
source  machine  for  subsequent  conversion  to 
COBOL  on  a  target  machine. 


Data  File 


Agency  information  stored  in  a  format  used  by 
automated  information  systems. 


Emulate 


Use  of  firmware  to  allow  original  code  to  run  on 
target  hardware  No  functional  change. 


Functional  User 


User  of  an  automated  information  systems  that 
supports  an  agency  operational  function  (e.g., 
personnel,  finance). 


Operation  Control 
Stream  Lar^uage 


A  generic  term  for  Control  Language, 
e.g.  IBM's  Job  Control  Language  (JCL) 


Parallel  Testing 


Parallel  testing  consists  of  operating  the  converted 
target  software  in  a  parallel,  operational  mode 
with  source  software  to  ensure  that  the  old  and 
new  systems  conform  functionally  and  that  the  new 
source  systems  run  in  an  acceptable  operational 
mode  with  other  systems. 
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Phase 


A  distinct  period  of  time  in  a  software  conversion 
project  where  certain  activities  are  performed. 
The  completion  of  all  activities  in  the  phase  leads 
to  the  next  phase,  ag.  conversion  planning  should 
precede  conversion  preparation  which  should 
precede  actual  conversion. 


Program 
Project  Manager 


Smallest  amount  of  stand  alone,  executable  code. 


The  full-time  manager  of  a  software  conversion 
project 


Project  Team 


Personnel  appointed  or  assigned  to  participate  in  a 
software  conversion  project  The  project  team 
size  and  skills  can  change  by  phase,  depending  on 
the  project  requirements  Team  members  can  be 
assigned  from  agency  resources  or  from  outside 
resources  (i.e.  consultants,  contractors). 


Recede 


A  translation  of  source  code  to  an  equivalent  line 
of  code  on  the  target  hardware  such  that  the 
functional  specifications  remain  the  same.  May  be 
accomplished  manually  or  with  automated  tool(s). 


Redesign 


A  change  in  system  specifications,  including 
different  algorithms  to  accomplish  the  same 
function  as  source  code.  No  change  to  functional 
specifications. 


Reprogram 


A  functional  translation  where  some  or  all  new 
code  is  produced  utilizing  new  logic  where 
necessary.  No  change  to  functional  specifications. 


Resource  Utilization 


A  measure  of  work  units  needed  to  process  the 
current  workload  or  the  source  system. 


Simulate 


Use  of  specialized  code  to  allow  original  source 
code  to  run  on  target  hardware.  No  change  to 
functional  specifications. 
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Software  Conversion 


The  transformation,  without  functional  change,  of 
computer  programs  or  data  elements  to  permit 
their  use  on  a  replacement  or  changed  ADP 
equipment,  environment,  teleprocessing  service  or 
system. 


Software  Conversion 
Manager 


The  agency  staff  member  who,  next  to  the 
conversion  project  manager,  has  the  greatest 
technical  interest  in  the  status  of  the  software 
conversion  project.  This  guide  assumes  that  the 
software  conversion  manager  will  have  normal 
responsibilities  for  day-to-day  software  operations 
and  lack  sufficient  additional  time  to  manage  the 
software  conversion  project.  A  full-time  project 
manager  will  thus  be  assigned  and  work  with  the 
software  conversion  manager  during  conversion. 


System  Software 


A  set  of  programs  that  encompass  or  support  the 
operating  system. 


Task  Sub-elements    of    work    related    to  conversion 

activities.  For  example,  tasks  related  to 
converting  an  application  system  could  include 
converting  the  source  code,  data  files  or  job 
stream  lar^uage. 

Test  Data  Data  that  is  used  to  test  software.  Unit  test  data 

usually  is  constructed  to  test  technical  aspects  of 
software  and  does  not  necessarily  correspond  to 
actual  data.  Systems  test  data  normally  represents 
operational  data.  Parallel  test  data  usually  is 
operational  data- 


Top  Management 

(Top  agency  executives)  Organizational  levels  of  management  above  the 

ADP  level  with  broad  authority  and  oversight  over 
many  or  all  agency  operations;  top  management 
has  authority  for  approving  buckets  and  allocating 
resources. 


Translate  A    change    in   language   or   version   only  (e.g., 

COBOL/68  to  COBOL/74)  No  change  in  functional 
or  detail  specifications.  (FCSC  definition). 
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No  charge  in  function  or  detail  specifications  and 
no  change  in  lar^age.  (FCSC  definition).  Occurs 
on  a  code-compatible  conversion. 

The  compilation,  execution  and  testing  of  each 
target  program  with  its  test  data.  Unit  test  data 
technically  tests  the  software  and  does  not 
necessarily  correspond  to  operational  data. 
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(both  government  and  non-government).  In  general,  initial  dis- 
tribution is  handled  by  the  sponsor:  public  distribution  is  by  the 
National  Technical  Information  Service  ,  Springfield,  VA  22161, 
in  paper  copy  or  microfiche  form. 
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